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LETTERS 


SDI: An unsound definition of reliability 


To the editor: 

Ware Myers’ report in the January 
1989 issue of Computer, “Software 
Pivotal to Strategic Defense,” sum¬ 
marizing the Second International Con¬ 
ference on Software for Strategic 
Systems in Huntsville, Alabama, high¬ 
lights the flimsiness of the argument in 
favor of the Strategic Defense Initiative 
(SDI), a.k.a. Star Wars. 

One participant observed, “The con¬ 
cerns about SDS (Strategic Defense Sys¬ 
tem) seem to focus on the testability of 
the software under conditions compara¬ 
ble to war.” Of course, other serious 
objections to SDI exist—it violates the 
ABM treaty, it is fabulously expensive, 
it might precipitate a nuclear war 
instead of forestalling one, and it 
ignores other attacks, such as manned 
bombers, cruise missiles, smuggled 
bombs, and suborbital bombardment. 

Even supporters of SDI concede that, 
“because we cannot test SDS in a live 
wartime environment, battle simula¬ 
tions on a scale needed to represent a 
full battle realistically are required.” 

The crucial question is, How much can 
full battle simulations or other peace¬ 
time testing tell us about the reliability 
of big software projects? Myers’ report 
mentions the space shuttle and “offen¬ 
sive missile forces” as “existence 
proofs” that “very large systems can 
reach near-zero significant defects.” 
Clearly, the shuttle’s software failed 
during the first launch: the launch was 
cancelled shortly before lift-off, and a 
bug had to be found and fixed before 
the shuttle could fly. The shuttle experi¬ 
ence proves that even with 15 years of 
development and four flight tests, the 
state of the software art is insufficient 
to produce functional software that 
works the first time it is actually used. 
And, of course, getting the shuttle to 
work in peacetime is childish play com¬ 
pared to getting SDI to work in 
wartime. 

It is fallacious to use systems like the 
Safeguard ABM system and the offen¬ 
sive missile forces as an existence proof 
that very large systems can be reliable 
even though they have not been tested 
in a live wartime environment. These 
systems are assumed reliable because 
they passed battle simulations and other 
peacetime tests. But the credibility of 
these simulations and other peacetime 


tests is precisely the issue at hand. 

This was unconsciously highlighted 
by the keynote speaker of the confer¬ 
ence: “These tests [of the components 
of offensive missiles] and simulations, 
taken together, constitute a high level of 
confidence that the system will work 
when activated in wartime. No one can 
guarantee that the system will not fail 
... yet it has served for 30 years as the 
centerpiece of the nation’s security.” 
This is double talk—if no one can guar¬ 
antee that the system will work, then 
how can it be reliable? The fact that the 
system has not been used in 30 years 
does not guarantee that it would work if 
it were used. 

These two existence proofs reveal the 
real definition of reliability used by sup¬ 
porters of untestable systems—namely, 
a system is reliable when it passes a test 
designed by a lot of “hard working” 
and “intelligent” people spending lots 
of money. That’s all. SDI need not do 
what it is supposed to do, nor what the 
requirements say it will do, nor what 
anyone might have a right to expect it 
will do. No indeed. There can be no 
demonstrated relationship between 
requirements and performance, so such 
a relationship is excluded from the defi¬ 
nition of reliability. 

The statement, “Those who believe 
that SDI cannot be done should get out 
of the way of those who believe it can 
be done,” makes sense in this context. 
Given a test of any system, one can 
design a system that passes the test—if 
it can’t pass the first test, make an eas¬ 
ier test, and if that test fails, why, just 
classify the results and cover up the 
truth. 

One speaker at the conference 
claimed, “Improved semantic analysis 
and formal testing should decrease 
error rates in delivered software by a 
factor of 10.” There is no basis for this 
wild hope, and even assuming, mirabile 
dictu, that errors could be reduced by a 
factor of 10, the idea of “getting the 
errors down” to only 2,000 to 6,000 
defects, and then claiming that the sys¬ 
tem is reliable, borders on the surreal. 

The arguments in favor of SDI over¬ 
look fundamental design flaws and 
focus on dubious and speculative possi¬ 
bilities. They ignore the clearest distinc¬ 
tions: that is, the difference between 


building an offensive missile, whose 
chief mission is to destroy a large, vul¬ 
nerable, unmoving, known target such 
as a city, and SDI, whose mission is to 
destroy a small, fast moving, incoming 
missile, protected with unknown 
countermeasures—or the difference 
between going to the moon, which does 
not involve outwitting hostile humans, 
and getting SDI to work, which does. 

In short, SDI can only be called relia¬ 
ble by tampering with the very notion 
of reliability itself. Not all of the con¬ 
ferences, speeches, statistics, or 
appropriations in the world will change 
this fact. SDI has no intellectual 
credibility—it is the “creation science” 
of the engineering world. Blandly 
reporting the double talk from the latest 
SDI conference is no service to the pub¬ 
lic. Who, except those bellying up to the 
federal feed trough, can think that SDI 
is worth $30 billion in software develop¬ 
ment costs? As an engineer, I say, let’s 
build projects that actually work. As a 
taxpayer, I say, SDI is an outrageous 
grab for the federal purse, bleeding 
money away from legitimate projects, 
both military and civilian. Let’s stop the 
SDI boondoggle. 

Edward K. Rean 

Madison, Wise. 


Author’s reply: 

Lest some think there is “no basis for 
this wild hope” that error rates can be 
reduced by a factor of 10, let me cite 
Harlan D. Mills, Michael Dyer, and 
Richard C. Linger, writing in the Sep¬ 
tember 1987 IEEE Software : “Current 
post-delivery levels in ordinary software 
are one to 10 errors per thousand lines. 
Good methodology produces post¬ 
delivery levels under one error per thou¬ 
sand lines.” 

My article in the September 1988 
IEEE Software provided further infor¬ 
mation on IBM’s achievement in getting 
errors in the space shuttle on-board 
software down to 0.11 per thousand 
lines. This rate was achieved with 
widely known technologies effectively 
used. 

These rates are not zero, of course. In 
the case of SDI these residual errors 
may well let some missiles through. 

That is why people say “War is hell.” 

Ware Myers 

Contributing Editor 

Since the publication of Myers’ 
report, Computer has received a num¬ 
ber of letters and inquiries regarding 
SDI. One of these inquiries may lead to 
a proposal for a special issue addressing 
the topic. Ed. 
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SURVEY & TUTORIAL SERIES 



The Abingdon Cross 
Benchmark Survey 

Kendall Preston, Jr. 

Carnegie Mellon University and University of Pittsburgh 


I mage processing means different 
things to different people. When 
you adjust the contrast and bright¬ 
ness on a television set, the image on the 
screen changes. This is image process¬ 
ing. The radiologist, sitting in front of 
the computer tomography screen, per¬ 
forms image processing when using a 
trackball to change “level” and “win¬ 
dow” settings to regulate the average 
value and the range of values of the CT 
numbers displayed. Image processing is 
performed on weather satellite images to 
generate the color displays seen on the 
TV evening news weather reports. 

Perhaps the most elaborate form of 
image processing is that conducted by 
the minisupercomputers installed in ro¬ 
bot microscopes in hematology laborato¬ 
ries, used to perform the white blood cell 
differential count. Using special televi¬ 
sion cameras operating at 100 frames per 
second, 100,000 human red cells are 
scanned in about a minute to find the 100 
white cells whose images must be digit¬ 
ized and analyzed to produce the re¬ 
quired results. 

Image-processing systems appeared in 



Conventional 
benchmarks don’t suit 
image-processing 
computers. The 
Abingdon Cross 
benchmark tests many 
common components 
of these unique 
computers. 


the 1950s when researchers first coupled 
television cameras to electronic comput¬ 
ers. Vacuum-tube computers built at that 
time performed pulse-height and pulse- 
width analysis of the television signal 
and showed the results on visual dis¬ 
plays. Perhaps the first example of such 


systems was the flying-spot microscope 
of Causley and Young, 1 which automati¬ 
cally counted all objects in a television 
field in four seconds — about 100 times 
faster than the human eye and brain. 

Since then we have seen steady growth 
of image-processing applications in 
many fields, including television micro¬ 
scopy, commercial and military satellite 
reconnaissance, medical radiology, and 
industrial inspection. With this growth 
in applications, innumerable commer¬ 
cial systems have appeared. There are 
now 700 or more companies active in 
what E.F. Hutton 2 calls El, or electronic 
imaging, of which image processing is a 
subset. 

Although in the past a relatively nar¬ 
row selection of image-processing 
equipment was available, we now have a 
bewildering array of choices. Clearly, 
we need a method to evaluate or bench¬ 
mark test such equipment. 

This article reports on the status of 
preliminary efforts to evaluate image- 
processing computers. As Duff stated, 3 
“It is becoming apparent that conven¬ 
tional benchmarking techniques are not 
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List of machines tested 


The following lists the machines tested, their manufacturers, and contacts. Results for commercial 

machines appea 

in Figure 7, while those for noncommercial machines appear in Table 6. 

Machine 

Manufacturer 

Contact * 

1024XM 

MegaVision (Santa Barbara, Calif.) 

Bernard Jean 

AIS-1000* 

Applied Intelligent Systems (Ann Arbor, Mich.) 

Stephen Wilson 

AIS-4000 

Applied Intelligent Systems (Ann Arbor, Mich.) 

Stephen Wilson 

AIS-5000 

Applied Intelligent Systems (Ann Arbor, Mich.) 

Stephen Wilson 

CAAPP 

University of Massachusetts (Amherst, Mass.) 

Charles Weems 

CAM-6 

Systems Concepts (San Francisco) 

Oliver Graves 

Centipede 

Applied Intelligent Systems (Ann Arbor, Mich.) 

Stephen Wilson 

CLAP 

Cellular Logic Systems (Annapolis, Md.) 

Robert Jernigan 

CLIP* 

Stonefield-Omicron (Horsham, UK) 

M.A. Erdenturg 

CLIP4 

University College London (London) 

Michael Duff 

CM-1 

Thinking Machines (Cambridge, Mass.) 

Gary Rancourt 

Cyto-HSS 

Environmental Research Institute of Michigan 



(Ann Arbor, Mich.) 

Robert Lougheed 

Cyto III 

Environmental Research Institute of Michigan 



(Ann Arbor, Mich.) 

Robert Lougheed 

DAP32 

International Computers Ltd. (London) 

Stuart Reddaway 

DAP64 

International Computers Ltd. (London) 

Stuart Reddaway 

DAP510 

Active Memory Technology (Irvine, Calif.) 

Rex Thanakij 

DIFF3/50* 

Coulter Biomedical Research (Bedford, Mass.) 

Don Graham 

DIP 

University of Delft (Delft, Holland) 

Robert Duin 

FLIP 

Froschungs-lnstitut fur Informationsverarbeitung under 



Mustererkennung (Karlsruhe, W. Germany) 

Peter Gemmar 

GAPP 

Martin Marietta (Orlando, Fla.) 

Wade Pemberton 

GE WARP 

General Electric (Syracuse, N.Y.) 

Craig Pickering 

IP8500 

Gould Imaging Systems (Freemont, Calif.) 

Olaf Kubler 



(ETH Zurich) 

IP9200 

Perceptics (Knoxville, Tenn.) 

James Youngberg 

Magiscan 

Joyce-Loebl (Garden City, N.Y.) 

John Gayler 

MaxVideo 

Datacube (Peabody, Mass.) 

Shepard Siegel 

MPP 

Goodyear Aerospace (Akron, Ohio) 

James Strong 



(NASA Goddard, Md.) 

MV2000* 

Machine Vision International (Ann Arbor, Mich.) 

Stanley Sternberg 

MV-G7* 

Machine Vision International (Ann Arbor, Mich.) 

Stanley Sternberg 

MVP/AT 

Matrox (Dorval, Canada) 

Raymond Snow 

PHP 

Carnegie Mellon University (Pittsburgh) 

Kendall Preston, Jr. 

PICAP-1 

University of Linkoping (Linkoping, Sweden) 

Bjorn Kruse 

PICAP-3 

University of Linkoping (Linkoping, Sweden) 

Per-Erik Danielsson 

PIP-4000** 

ADS Company Ltd. (Tokyo) 

Kozaburo Baba 

PIP-4500 

ADS Company Ltd. (Tokyo) 

Kozaburo Baba 

Pixar-1 

Pixar (San Rafael, Calif.) 

Michael Mantle 

Pixar-3 

Pixar (San Rafael, Calif.) 

Michael Mantle 

POP II Royal 

Holloway College (Egham Hill, UK) 

E.R. Davies 

PSICOM 327 

Perceptive Systems (Houston) 

Kenneth Castleman 

Scope-20/512 

Symbolics Graphics Division (Los Angeles) 

Anoosh Mostowfi 

SPDS 

Amber Engineering (Goleta, Calif.) 

Jeff Frank 

Sympati-2 

Institut Universitaire de Technologie (Toulouse, France) 

Jean Basille 

TAS 

Leitz GmbH (Wetzler, W. Germany) 

Reiner Nawrath 

Teragon 

Teragon (Linkoping, Sweden) 

Bjorn Kruse 

Tospix II 

Toshiba (Kawasaki City, Japan) 

Masatsugu Kidode 

Trapix 5500 

Recognition Concepts Inc. (Incline Village, Nev.) 

Hassan Mostafavi 



(Tau Corp.) 

VAP 

University of Berne (Berne, Switzerland) 

A. Favre 

Vicom 

Vicom (San Jose, Calif.) 

Timothy Richardson 

Viper 

Amber Engineering (Goleta, Calif.) 

Jeff Frank 

Vitec-1 

Visual Information Technologies (Plano, Tex.) 

Timothy Butler 

Vitec-3 

Visual Information Technologies (Plano, Tex.) 

Parveen Gupta 

WARP 

Carnegie Mellon University (Pittsburgh) 

H.T. Kung 

* No longer in production. 


** Sold in the US as 

the VIA000 by Boeckeler Instruments, Tucson, Ariz. 
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readily applicable to this new class of 
computer.” I therefore began develop¬ 
ing new methods for benchmarking these 
computers in 1980. 4 This work expanded 
in 1982 when, at an international meet¬ 
ing on architectures, algorithms, and lan¬ 
guages for image processing held in 
Abingdon, Great Britain, I was asked to 
devise a benchmark test for image-pro¬ 
cessing computers. The result was the 
Abingdon Cross benchmark. 5 By 1984 
approximately 30 government, indus¬ 
trial, and university groups were partici¬ 
pating in the Abingdon Cross benchmark 
survey. Since then this benchmark sur¬ 
vey has expanded to include more than 
100 organizations. Results from testing 
51 machines are presented here. (See the 
accompanying sidebar for a list of the 
machines and their producers.) 

Image processing 

The diversity of image-processing 
applications mentioned above makes 
benchmarking difficult. Table 1 lists the 
major operations required of an image- 
processing system. Figure 1 shows ex¬ 
amples of image processing, some tested 
by the Abingdon Cross benchmark. In 
the upper left comer of the figure is an 
aerial photograph furnished from SIDBA 
(Standard Image Data Base) by the Im¬ 
age Processing Center, Institute of In¬ 
dustrial Science, University of Tokyo. 
Modifications of this photograph shown 
in the first two rows are examples of 
arithmetic point operators, where a 
lookup table is used to map each input 
value to an output value. (Figure 2 graphs 
the contents of these tables.) The map¬ 
pings shown are linear spread, biased 
logarithm, exponential, equalization, 
threshold, brightness contours (iso- 
photes), and overlaid isophotes. 

The four frames in the third row illus¬ 
trate certain image transforms, including 
6x6 averaging, Laplacian, 6x6 median, 
and 6x6 binary median. Averaging and 
median transforms are linear and nonlin¬ 
ear low-pass filters, respectively. The 
Laplacian is a high-pass filter. 

The last four frames illustrate cellular 
logic opening, cellular logic closing, the 
medial axis of the cellular lo^ic closing, 
and an overlay of the medial axis on the 
6x6 median, respectively. Cellular logic 
transforms are the most complex opera¬ 
tions shown in Figure 1 (see my survey in 
the January 1983 Computer 6 ). Cellular 
logic openings reduce dark areas while 


Table 1. Basic image-processing opera¬ 
tions. 


Utilities 

Storage allocation 
Program control 
Formatters 
I/O commands 
Test-pattern generators 
Help files 

Geometric 

Scaling/rotation 
Rectification 
Mosaicing/registration 
Map projection 
Gridding/masking 

Transforms 

Noise removal 
Fourier analysis and other 
spectral transforms 
Power spectrum 
Filtering 
Cellular logic 

Arithmetic 

Point 

Line (vector) 

Matrix 

Complex number 
Boolean 

Measurement 

Histogramming 

Statistical 

Numerical and geometric 

Decision theoretic 

Feature select (training) 
Classify (unsupervised) 
Classify (supervised) 
Evaluate results 

Display 

CRT 

Hardcopy 

Interactive graphics 


augmenting light areas. Closings do the 
reverse. 

Generation of the medial axis is also a 
cellular logic operation. The medial axis 
is a graph expressing the interrelation¬ 
ships among various components of the 
image. In the case illustrated, this graph 
describes the structure of white areas in 
the cellular logic closing of the median 


filtered image. This particular medial 
axis consists of nine disjoint subgraphs, 
three of which are essentially single 
points, while the others represent both 
the curvature and orientation of the light 
areas in the binary closing. Counting and 
locating endpoints, nodes, closed poly¬ 
gons, and arcs in these subgraphs pro¬ 
vides descriptive information on the 
structure of the image. For example, the 
fact that there are three small closed 
polygons (two in one subgraph, one in 
another) indicates that, in the original 
image, there are three small dark areas 
totally enclosed by white areas. This and 
other information elucidated by the me¬ 
dial axis may be used in automated pat¬ 
tern recognition. 

Unique features of image process¬ 
ing. A unique feature of image-process¬ 
ing systems is the enormous size of the 
data arrays to be manipulated. Although 
many images, such as those in medicine, 
are as small as one or two megabytes, 
typical commercial and military multi- 
spectral satellite images range from 50 
megabytes per frame (from Landsat) to 
250 megabytes (from SPOT) to 500 
megabytes (from GEOS), with the latter 
producing 10 gigabytes of new image 
data each day. No ordinary computer 
system can handle the tens of thousands 
of gigabytes now archived by such sys¬ 
tems or process this data at the rates 
required by the user. This explains why 
so many special-purpose image-process¬ 
ing computers have been designed. 

The image-processing computer sys¬ 
tem clearly must have an integrated hier¬ 
archy of tape, disk, and semiconductor 
memory to handle large archives. An¬ 
other unique feature is the requirement 
for dedicated high-speed processing 
units for executing the most frequently 
used transforms in hardware. Immediate 
transfer of results to the display is also 
important, since image processing re¬ 
quires a close interactive coupling of 
machine to user. The user tests and re¬ 
tests each step in an image-processing 
procedure by observing its effect, via the 
display, on the overall process. Produc¬ 
tive use of such systems in algorithm 
development requires immediate re¬ 
sponse. Each image transform should 
return its result to the display screen in a 
second or less. 

Benchmarking. Benchmarking of 
general-purpose computers is, of course, 
well known. For example, the Los 
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Figure 1. Typical image-processing operations executed on the 128x128 pixel 
aerial photograph (upper left corner). The top two rows show the results of 
using the arithmetic point operators graphed in Figure 2. The third row 
shows, respectively, an averaging transform, the Laplacian transform, the 
median Fdter, and the thresholded median. The bottom row shows a cellular 
logic opening of the thresholded median, a cellular logic closing, the medial 
axis of the cellular logic closing, and an overlay of the result on the median 
filtered image from which it was derived. (Photo recording courtesy of 
Crosfield Dicomed, Minneapolis, Minn.) 


Alamos benchmarks have been widely 
employed to evaluate supercomputers in 
the United States and Japan, as reported 
in a 1985 article in this magazine. 7 As 
pointed out there, “No benchmark 
should be undertaken without a workload 
characterization.” Therefore, the Los 
Alamos benchmarks are typical of pro¬ 
grams run frequently at the United States 
Department of Energy Laboratories both 
at Los Alamos and Livermore, including 
Monte Carlo particle transport and fast 
Fourier transform. 7 

Benchmarks of the Los Alamos vari¬ 
ety are entirely suitable to general-pur¬ 
pose computers, which have more or less 
standard computing features. Unlike 


general-purpose computers, image-proc¬ 
essing systems vary enormously not only 
in the characteristics of their ALUs, but 
also in the architecture that connects 
these ALUs, as well as in the methodol¬ 
ogy by which image data is moved to and 
from the ALU array. 

Other benchmarks are discussed in the 
literature. 810 Of these, only the Intel 
Automated Parts Inspection Benchmark 
relates to image processing. This bench¬ 
mark is specific to industrial inspection, 
where the image-processing computer 
under evaluation must read image data 
from analog/digital converters, store the 
data as an array of 128x128 picture 
points, and perform a zero-shift convolu¬ 


tion with respect to a reference image. Its 
purpose is to determine whether the in¬ 
put data is within tolerance with respect 
to the reference. I know of no paper that 
provides results of the Intel benchmark 
for large^ numbers of image-processing 
systems. 

The Abingdon Cross 

Lindskog’s dissertation" described 
the Abingdon Cross as follows: 

The Abingdon Cross is a benchmark 
method for comparing the performance of 
image-processing architectures. As with 
other benchmarks, it does not cover all as¬ 
pects, but provides at least a coarse means for 
comparison. 

The task is to find the medial axis of a cross 
in [a noisy] background. Any algorithms may 
be used when the total execution time is the 
only factor considered. The problem essen¬ 
tially consists of two parts: linear and nonlin¬ 
ear. The linear part is the edge-detection and 
separation from the background. The nonlin¬ 
ear operations encompass the endoskeletoni- 
zation or connectivity-preserving thinning 
[medial axis transform] of the cross. In order 
that the edge-detection part not be trivial, the 
cross is imbedded in a significant amount of 
noise. The signal to noise ratio for the arms of 
the cross is 0 dB. [See Figure 3.] 

Because most modem image-processing 
systems process 8-bit pixels, this was also 
chosen for the input image of the cross. The 
spatial resolution of the image on the other 
hand may be adapted to the architecture. The 
final result is compensated for the image size. 
The total execution time for all steps in finding 
the medial axis is measured and used to com¬ 
pute the normalized performance figure. If the 
total time is T, and the image size is NxN, a nor¬ 
malized value called the quality factor, QF = 
NIT , can be computed... and the performance- 
cost ratio = AF/TC. C is the total system cost in 
USD [United States Dollars] and CP can be 
interpreted as the amount of processing power 
per dollar. 

I use PPF (price-performance factor) 
in place of Lindskog’s CP. 

The Abingdon Cross is a compromise 
between the full and rigorous set of 
benchmarks required to execute and test 
all operations in Table 1 and a bench¬ 
mark simple enough that each prospec¬ 
tive participant would be likely to under¬ 
take its execution. It was designed to test 
as many common components of image- 
processing computer systems as pos¬ 
sible. Referring to Table 1, it tests (1) in¬ 
put/output, (2) matrix and/or vector op¬ 
erations, (3) Boolean operations, (4) fil¬ 
tering, and (5) cellular logic. 
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Figure 2. Arithmetic point operators used to generate the images in the first 

two rows of Figure 1. 


Table 2. Kubler’s results using the IP8500. 


Operation 

Time 

Figure 

Threshold at level 140 

33 ms 

3b 

Median transform (over a 17-pixel vertical run) 

561 ms 

3c 

Median transform (over a 17-pixel horizontal run) 

561 ms 

3d 

Median transform (over a 3x3 kernel) 

594 ms 

3e 

Skeletonization 

4,752 ms 

3f 


Figures 3 through 6 present a variety 
of results submitted by some of the par¬ 
ticipants in the Abingdon Cross bench¬ 
mark survey. 

Most of the results reported here are 
timely but, since the Abingdon Cross 
survey has been in progress since 1982, 
some data may not reflect the current 
status of certain systems. In general, I 
received all data in writing, based on 
either actual runtimes or runtimes esti¬ 
mated from actual code. In many cases I 
witnessed the benchmark, or my col¬ 
leagues or students did, and often it was 
documented by photographic evidence. 
Of the more than 100 such photographs 
submitted, 22 are reproduced in this 
report. 

The IP8500 videorate processor. 

Kubler of ETH (Eidgenossische Tech- 
nische Hochschule) in Zurich, using the 
Gould IP8500 (from Gould Imaging Sys¬ 
tems in Freemont, California) obtained 
the results shown in Figure 3. Starting 
with the cross itself (Figure 3a), Kubler 
summarized his results 5 as shown in 
Table 2. The array processed had N =512 
pixels which, with an execution time of 
6.5 seconds, yields a quality factor of 79. 
The PPF is 0.4. 

The MaxVideo subarray processor. 

Whereas Kubler immediately thresh- 
olded the cross, Siegel and Watkins 12 
used the MaxVideo image processor 
(from Datacube of Peabody, Massachu¬ 
setts) to perform the benchmark using 
linear filtering, as shown in Figure 4. The 
cross (Figure 4a) was filtered using a 
large convolution kernel (64x64) em¬ 
ploying the MaxVideo module to per¬ 
form a programmable aperture moving 
average filter (Figure 4b). The result was 
thresholded (Figure 4c) and “noise 
cleanup’’ was performed (Figure 4d) by 
what Siegel calls a “binary morphologi¬ 
cal transformation to remove pathologi¬ 
cal defects in the thresholded image.” 
After this the result is eroded (Figure 4e) 
and the medial axis found (Figure 4f). 
Siegel, in a letter to me, summarized the 
operations as shown in Table 3. The 
image size Siegel used had V=512. The 
execution time was 243 milliseconds, 
yielding a quality factor of 2,107. The 
PPF is 40. See Siegel and Watkins’ ar¬ 
ticle 12 for details. 


Table 3. Siegel’s and Watkins’ results 
using the MaxVideo. 


Operation Number of Passes 


Linear filtering 1 

Thresholding 1 

Cleanup 1 

Medial axis transform 33 


The Tospix II instruction set proces¬ 
sor. Some image-processing architec¬ 
tures hardwire each important subrou¬ 
tine in a special-purpose processing unit, 
which Reddy called “instruction set 


processors.” 13 An example is Tospix II 
(from the Toshiba Research and Devel¬ 
opment Center in Kawasaki, Japan), 
which has hardware subroutines for exe¬ 
cuting Fourier transforms, 3x3 binary 
neighborhood transforms, binary object 
counting, etc. 

In describing the results obtained for 
the Abingdon Cross benchmark using 
Tospix II, Kidode wrote 5 

We have tried two different kinds of algo¬ 
rithms to study the trade-off between process¬ 
ing time and output quality. The major differ¬ 
ence between two algorithms is how to remove 
noise. The first algorithm employs a region¬ 
labeling function to remove bloblike noise at 
one cycle, which can save preprocessing time. 
The second algorithm used a certain number of 
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Table 4. Kidode's steps using Tospix II. 


Operation 

Time 

Figure 

Thresholding 

50 ms 

5b 

Noise reduction 

50 ms 

5c 

Filling* holes 

450 ms 

5d 

Erosion 1,240 ms 

5e 

Skeletonization 

530 ms 

5f 



Figure 3. Execution of the Abingdon Cross benchmark submitted by ETH 
(Zurich, Switzerland) showing (a) the cross, (b) the thresholded cross, (c) the 
vertical median transform, (d) the horizontal median transform, (e) the 
smoothing transform, and (f) the final result (superimposed on e). (Reprinted 
with permission of Academic Press, Cambridge, Mass., copyright 1986.) 


logical operations to iteratively remove noise. 
Since this algorithm smoothes edges of the 
cross pattern, more smooth skeleton informa¬ 
tion can be obtained... 

The first algorithm developed by Ki- 
dode included the steps listed in Table 4 
and illustrated by Figure 5. 

Kidode further stated 5 


The [threshold] operation was executed at 
high speed by a hardwire point mapping func¬ 
tion. .. The following logical operation, with a 
kind of majority rule, [was used] to reduce 
pepper and salt noise in both cross pattern and 
background. Let W be the number of Is in the 8 
neighborhood of a certain pixel, then if N was 
less than 3, the pixel was set to 0; greater than 
5, set to 1; otherwise, unchanged. This opera¬ 
tion was realized by high-speed logical filter¬ 


ing operation. . . Filling in holes [was carried 
out] when black regions (background) whose 
area was less than 1,000 were filled in. This 
was realized using table processing software 
and three hardware modules; region labeling, 
histogramming, and point mapping. Twenty- 
eight cycles of erosion [were chosen so that] 
the number of erosion cycles [did not] cut the 
cross. Five cycles of skeletonization [used] 
Deutch’s algorithm. 

Since Tospix II had Af=512 with a com¬ 
putational time of 2.32 seconds, the qual¬ 
ity factor for this algorithm is 221. The 
PPF is close to unity. 

Massively parallel arrays. Massively 
parallel image-processing systems use 
an array of thousands of relatively ele¬ 
mentary, binary arithmetic logic units to 
perform computations on image data. 
The first commercial processor of this 
type was the 32x32 DAP (from Interna¬ 
tional Computers in Great Britain). Its 
1,024 ALUs were arranged in a square 
array that defined a window in the larger 
array of image data. One of the problems 
in the square arrangement of processing 
elements is that, when image data is first 
entered in the array, it is stored in row or 
column ALUs and then must be propa¬ 
gated across the array before computa¬ 
tions can commence. Although, in many 
massively parallel square architectures, 
computation and propagation can occur 
simultaneously, there is always the pos¬ 
sibility that the process can become I/O 
bound when the computational time is 
shorter than the propagation time. 

An alternative architecture, repre¬ 
sented by the AIS-5000 (from Applied 
Intelligent Systems in Ann Arbor, Michi¬ 
gan), is to use a linear array of processors 
(either 512 or 1,024) to manipulate im¬ 
age data one row or one column at a time. 
This configuration has turned out to be 
more cost effective than the square array 
in many applications. An example taken 
from the AIS-5000 is shown in Figure 6. 
In his paper on the AIS-5000, Wilson 14 
stated “. . . the AIS-5000 is able to 
perform the Abingdon Cross benchmark 
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Figure 4. Execution of the Abingdon Cross benchmark submitted by Datacube (Peabody, Mass.) showing (a) the ere 
(b) the result of a 64x64 linear convolution, (c) thresholding, (d) noise removal, (e) partial erosion, and (f) the final 


result. 



Figure 5 Execution of the Abingdon Cross benchmark submitted by Toshiba (Kawasaki City, Japan) showing (a) the 
cross, (b) thresholding, (c) noise reduction, (d) filling holes, (e) partial erosion, and (0 the final result super.mposed 

on (a). (Reprinted with permission of Academic Press, Cambridge, Mass., copyright 1986.) 
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Figure 6. Execution of the Abingdon Cross benchmark submitted by Applied 
Intelligent Systems (Ann Arbor, Mich.) showing (a) thresholding, (b) topology 
filtering, (c) openings and closings, and (d) skeletonization. 


Table 5. Wilson’s steps using the AIS- 
5000. 


Operation 

Time 

Figure 

Threshold 

0.4 ms 

6a 

Topology filters 

0.7 ms 

6b 

Openings/closings 

12.4 ms 

6c 

Skeletonization 

3.7 ms 

6d 


in 20 ms — better than most mesh-con¬ 
nected systems even though only 512 
PEs [processing elements] are used.” 
The results, shown in Figure 6, were 
summarized in a letter from Wilson to 
me as follows: 

Since the AIS-5000 is a bit-serial machine, 
best results on the Abingdon Cross are ob¬ 
tained using bit-serial processing. The cross is 
[initially] constructed using dilations of rec¬ 


tangles from a central seed point. [Additive] 
Gaussian noise is generated using the central 
limit theorem. The pictures are zoomed [2:1] 
so that detail is more apparent. The following 
steps [shown in Table 5] provide skeletoniza¬ 
tion of the cross. 

The array processed had A=512 pixels, 
yielding a quality factor of 26,000. The 
PPF is 300. 


Discussion 

Unlike the Los Alamos benchmarks, 
which require the participant to compile 
and execute specific lines of Fortran 
code, the Abingdon Cross benchmark 
presents the participant with an image- 
processing problem without specifying 
the algorithm to be employed in its solu¬ 
tion. This gives the programmer free rein 
to optimize the code for the machine at 
hand. I assume, of course, that the com¬ 


pany has sufficient incentive to assign a 
skilled programmer to this task so the 
capability of the image-processing sys¬ 
tem is tested, not the capability of the 
programmer. 

Of course, no single benchmark can 
completely exercise any image-process¬ 
ing system. However, it is unlikely that 
any institution would be willing to inter¬ 
rupt its schedule and assign staff to par¬ 
ticipate in the days of rigorous testing 
required to benchmark all of the opera¬ 
tions listed in Table 1. Thus, the Abing¬ 
don Cross benchmark, although a com¬ 
promise, represents a worthwhile initial 
step in the direction of rigorous bench¬ 
marking. The fact that the Abingdon 
Cross is being used as a touchstone by so 
many members of the image-processing 
community indicates its value. 

Of the more than 100 image-process¬ 
ing organizations surveyed, about half 
were unable to perform the benchmark 
for various reasons: (1) lack of time/ 
interest, (2) inadequate software, (3) 
hardware specific to other than the trans¬ 
forms required, and (4) involvement as a 
systems integrator without having a spe¬ 
cific image-processing workstation 
available for benchmarking. Organiza¬ 
tions have furnished me with results for 
39 commercial image-processing sys¬ 
tems and 12 noncommercial systems. 
Results for commercial systems are 
graphed in Figure 7, which plots the 
quality factor against the price-perform¬ 
ance factor. A glossary of the nomencla¬ 
ture used in this graph appears in the 
sidebar. Results for noncommercial sys¬ 
tems appear in Table 6, giving only the 
quality factor. 

Data plotted in Figure 7 clusters in 
four groups. The so-called “videorate 
processors,” such as the IP8500, appear 
in the lower left of the figure with quality 
factors ranging from 10 to 100 and price- 
performance factors ranging from 0.1 to 
unity. In the center of the figure a second 
group starts with Tospix II on the left and 
extends to the MaxVideo system on the 
right. These represent newer, specialized 
image-processing systems with architec¬ 
tures optimized to the high-speed ma¬ 
nipulation of large data arrays. A third 
group, represented by the trio MVP/AT, 
CLAP, and CAM-6, are board-level proc¬ 
essors intended as plug-in peripherals to 
the personal computer. Finally, extend¬ 
ing from the MPP on the left to the AIS- 
4000 on the right is a group representing 
the massively parallel processors. These 
differ far less in their quality factors than 
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Figure 7. Graph plotting quality factor against price-performance factor for 39 commercial systems. (See Table 6 
for results submitted for noncommercial systems.) Solid circles are measured results using actual hardware; open 
circles, calculated results on actual hardware; open squares, hypothetical results for hardware under development. 
For high performance systems (PPF>100), all used iV=512 except Viper, where N= 96. 


Table 6. Benchmark results for noncommercial systems. 


Machine 

Quality Factor 

Actual or Expected (calculated) 

CAAPP (64x64) 

1.3 • 10 s 

E 

CLIP4 (96x96) 

7.3 • 10 3 

A 

Cyto III 

1.0 • 10 2 

A 

DIP 

4.7 • 10 

A 

FLIP 

6.8 • 10 

E 

PHP 

7.1 

A 

PICAP-1 

1.0 • 10 

E 

PICAP-3 

7.5 • 10 3 

E 

POP II 

2.9 

A 

Sympati-2 

1.0 • 10 5 

E 

VAP 

1.8 ■ 10 

A 

WARP 

5.0 ■ 10 2 

A 


they do in price-performance. The al¬ 
most 1,000:1 ratio of PPFs for these 
systems is nothing less than astounding 
and illustrates the enormous increase in 
performance per dollar that has occurred 
over the past decade without a sacrifice 
in speed. 

No discussion of the Abingdon Cross 
benchmark should end without some 
comment on the use of a priori informa¬ 
tion. I quote here from remarks sent to 
me by Frans Gerritsen and Robert Duin 
of the University of Delft: 

A program that fulfills the tasks and that is 
completely independent of any knowledge of 
the image generation procedure is very hard to 
write. It would be a complete research project 
to remove the noise and find the skeleton of an 
arbitrary picture. That is certainly not the goal 
of the benchmark. It is therefore completely 
legitimate to use some a priori knowledge. On 
the other side, using all knowledge leads to 
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two graphic commands that generate perfectly 
the ideal skeleton of the cross. It seems to us 
that it is up to Preston and his evaluation of the 
benchmark results to take into account the 
differences in the a priori knowledge used by 
the participators. 

In reply I would like to note that par¬ 
ticipants have been permitted to use the 
following a priori information: (1) mean 
value of the noise, (2) signal-to-noise 
ratio, and (3) size of the cross relative to 
the size of the image. 

T he Abingdon Cross benchmark 
provides us with the first widely 
accepted test with which to 
measure the performance of image-pro- 
cessing computers. We now must con¬ 
tinue our work on developing more rigor¬ 
ous and comprehensive image-process¬ 
ing benchmarks. □ 
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Dynamic Instruction 
Scheduling and the 
Astronautics ZS-1 


James E. Smith 

Astronautics Corporation of America 


P ipelined instruction processing 
has become a widely used tech¬ 
nique for implementing high-per¬ 
formance computers. Pipelining first ap¬ 
peared in supercomputers and large 
mainframes, but can now be found in less 
expensive systems. For example, most of 
the recent reduced instruction set com¬ 
puters use pipelining. 1 - 2 Indeed, a major 
argument for RISC architectures is the 
ease with which they can be pipelined. At 
the other end of the spectrum, computers 
with more complex instruction sets, such 
as the VAX 8800, 3 make effective use of 
pipelining as well. 

The ordering, or “scheduling,” of in¬ 
structions as they enter and pass through 
an instruction pipeline is a critical factor 
in determining performance. In recent 
years, the RISC philosophy has become 
pervasive in computer design. The basic 
reasoning behind the RISC philosophy 
can be stated as “simple hardware means 
faster hardware, and hardware can be 
kept simple by doing as much as possible 
in software.” A corollary naturally fol¬ 
lows, stating that instruction scheduling 
should be done by software at compile 
time. We refer to this as static instruction 
scheduling, and virtually every new 
computer system announced in the last 
several years has followed this approach. 
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Dynamic instruction 
scheduling resolves 
control and data 
dependencies at 
runtime. This extends 
performance over that 
possible with static 
scheduling alone, as 
shown by the ZS-1. 


Many features of the pioneering CDC 
6600 4 have found their way into modem 
pipelined processors. One noteworthy 
exception is the reordering of instruc¬ 
tions at runtime, or dynamic instruction 
scheduling. The CDC 6600 scoreboard 
allowed hardware to reorder instruction 
execution, and the memory system stunt 
box allowed reordering of some memory 
references as well. Another innovative 
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computer of considerable historical in¬ 
terest, the IBM 360/91, 5 used dynamic 
scheduling methods even more exten¬ 
sively than the CDC 6600. 

As the RISC philosophy becomes ac¬ 
cepted by the design community, the 
benefits of dynamic instruction schedul¬ 
ing are apparently being overlooked. 
Dynamic instruction scheduling can 
provide performance improvements 
simply not possible with static schedul¬ 
ing alone. 

This article has three major purposes: 

(1) to provide an overview of and 
survey solutions to the problem of 
instruction scheduling for pipe¬ 
lined computers, 

(2) to demonstrate that dynamic in¬ 
struction scheduling can provide 
performance improvements not 
possible with static scheduling 
alone, and 

(3) to describe a new high-perform¬ 
ance computer, the Astronautics 
ZS-1, which uses new methods for 
implementing dynamic schedul¬ 
ing and which can outperform 
computers using similar-speed 
technologies that rely solely on 
state-of-the-art static scheduling 
techniques. 
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FDIEEEE 

FDIEEEE 

FDIEEEE 

FDIEEEE 


Figure 1. Pipelined instruction processing: (a) a typical pipeline; (b) ideal 
flow of instructions through the pipeline. 


in one cycle from a cache memory. 

(2) Instruction decode — the instruc¬ 
tion’s opcode is examined to determine 
the function to perform and the resources 
needed. Resources include general-pur¬ 
pose registers, buses, and functional 
units. 

(3) Instruction issue — resource 
availability is checked and resources are 
reserved. That is, pipeline control inter¬ 
locks are maintained at this stage. As¬ 
sume that operands are read from regis¬ 
ters during the issue stage. 

(4) Instruction Execution — instruc¬ 
tions are executed in one or several exe¬ 
cution stages. Writing results into the 
general-purpose registers is done during 
the last execution stage. In this discus¬ 
sion, consider memory load and store 
operations to be part of execution. 


TTTTTTTT 

S Snra £ 2 nk 

70 70 

Load register R1 from memory location Y 

Load register R2 from memory location Z 
Floating add registers R1 and R2 

Store the result into memory location X 

Load register R4 from memory location B 

Load register R5 from memory location C 
Floating multiply registers R4 and R5 

Store the result into memory location A 

R1 <— (Y) 

FDIEEEE 

R2 «- (Z) 

FDIEEEE 

R3 <- R1 +f R2 

FD...IEEE 

(X)<— R3 

F...D..IEEEE 

R4 <- (B) 

F..DIEEEE 

R5 <- (C) 

FDIEEEE 

R6 *- R4 *f R5 

FD...IEEE 

(A) <— R6 

F...D..IEEEE 


(b) 


Figure 2. Pipelined execution of X=Y+Z and A=B*C: (a) machine code; (b) 
pipeline timing. 


Introduction to 
pipelined computing 

Pipelining decomposes instruction 
processing into assembly line-like 


stages. Figure 1 illustrates a simple ex¬ 
ample pipeline. In Figure la, the pipeline 
stages are: 

(1) Instruction fetch — for simplicity 
assume that all instructions are fetched 


Figure lb illustrates an idealized flow 
of instructions through the pipeline. 
Time is measured in clock periods and 
runs from left to right. The diagram notes 
the pipeline stage holding an instruction 
each clock period. F denotes the instruc¬ 
tion fetch stage, D denotes the decode 
stage, / denotes the issue stage, and E 
denotes the execution stages. 

In theory, the clock period for a p- 
stage pipeline would be 1 Ip the clock 
period for a nonpipelined equivalent. 
Consequently, there is the potential for a 
p times throughput (performance) im¬ 
provement. There are several practical 
limitations, however, on pipeline per¬ 
formance. The limitation of particular 
interest here is instruction dependencies. 

Instructions may depend on results of 
previous instructions and may therefore 
have to wait for the previous instructions 
to complete before they can proceed 
through the pipeline. A data dependence 
occurs when instructions use the same 
input and/or output operands; for ex¬ 
ample, when an instruction uses the re¬ 
sult of a preceding instruction as an input 
operand. A data dependence may cause 
an instruction to wait in the pipeline for 
a preceding instruction to complete. A 
control dependence occurs when control 
decisions (typically as conditional 
branches) must be made before subse¬ 
quent instructions can be executed. 

Figure 2 illustrates the effects of de¬ 
pendencies on pipeline performance. 
Figure 2a shows a sequence of machine 
instructions that a compiler might gener¬ 
ate to perform the high-level language 
statements X = Y + Z and A = B * C. 
Assume load and store instructions take 
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four execution clock periods while float¬ 
ing-point additions and multiplications 
take three. (These timing assumptions 
represent a moderate level of pipelining. 
In many RISC processors fewer clock 
periods are needed. On the other hand, 
the Cray-1 requires 11 clock periods for 
a load, and floating-point additions take 
six. Cray-2 pipelines are about twice the 
length of the Cray-l’s.) 

Figure 2b illustrates the pipeline tim¬ 
ing. A simple in-order method of instruc¬ 
tion issuing is used; that is, if an instruc¬ 
tion is blocked from issuing due to a 
dependence, all instructions following it 
are also blocked. The same letters as 
before are used to denote pipeline stages. 
A period indicates that an instruction is 
blocked or “stalled” in a pipeline stage 
and cannot proceed until either the in¬ 
struction ahead of it proceeds, or, at the 
issue stage, until all resources and data 
dependencies are satisfied. 

The first two instructions issue on 
consecutive clock periods, but the add is 
dependent on both loads and must wait 
three clock periods for the load data 
before it can issue. Similarly, the store to 
location X must wait three clock periods 
for the add to finish due to another data 
dependence. There are similar blockages 
during the calculation of A. The total 
time required is 18 clock periods. This 
time is measured beginning when the 
first instruction starts execution until the 
last starts execution. (We measure time 
in this way so that pipeline “fill” and 
“drain” times do not unduly influence 
relative timings.) 

Instruction scheduling 

An important characteristic of pipe¬ 
lined processors is that using equivalent, 
but reordered, code sequences can result 
in performance differences. For ex¬ 
ample, the code in ^Figure 3a performs 
the same function as that in Figure 2a 
except that it has been reordered, or 
“scheduled,” to reduce data dependen¬ 
cies. Furthermore, registers have been 
allocated differently to eliminate certain 
register conflicts that appear to the hard¬ 
ware as dependencies. Figure 3b illus¬ 
trates the pipeline timing for the code in 
Figure 3a. Note that there is considerably 
more overlap, and the time required is 
correspondingly reduced to 11 clock 
periods. 

The above is an example of static in¬ 
struction scheduling, that is, the sched- 


R1 <- (Y) 

R2 <- (Z) 

R4 <- (B) 

R5 «- (C) 

R3 <- R1 +f R2 
R6 <- R4 *f R5 
(X)<—R3 
(A) <— R6 

(a) 


Load register R1 from memory location Y 
Load register R2 from memory location Z 
Load register R4 from memory location B 
Load register R5 from memory location C 
Floating add X and Y 
Floating multiply B and C 
Store R3 to memory location X 
Store R6 to memory location A 


R1 <- (Y) 

FDIEEEE 

R2 <- (Z) 

FDIEEEE 

R4 <- (B) 

FDIEEEE 

R5 <- (C) 

FDIEEEE 

R3 <- R1 +f R2 

FD.IEEE 

R6 R4 *f R5 

F.D.IEEE 

(X)<—R3 

F.DIEEEE 

(A)<— R6 

FD.IEEEE 


(b) 


Figure 3. Reordered code to perform X=Y+Z and A=B*C: (a) machine code; 
(b) pipeline timing. 



Figure 4. Block diagram of the CDC 6600-style processor. 


uling or reordering of instructions that 
can be done by a compiler prior to execu¬ 
tion. Most, if not all, pipelined comput¬ 
ers today use some form of static sched¬ 
uling by the compiler. Instructions can 
also be reordered after they have entered 
the pipeline, which is called dynamic 
instruction scheduling. Used in some 
high-performance computers over 20 


years ago, it is rarely used in today’s 
pipelined processors. 

Dynamic instruction scheduling: 
scoreboards. The CDC 6600 4 was an 
early high-performance computer that 
used dynamic instruction scheduling 
hardware. Figure 4 illustrates a simpli¬ 
fied CDC 6600-type processor. The CDC 
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time -» 

R1 <- (Y) 

R2 <- (Z) 

R3 <- R1 +f R2 
(X) <— R3 

R4 <- (B) 

R5 <- (C) 

R6 <- R1 *f R2 
(A) <— R6 

FDIEEEE 

FDIEEEE 

FDI...EEE 

FDI.EEEE 

FDIEEEE 

FDIEEEE 

FDI...EEE 

FDI.EEEE 

Figure 5. Pipeline flow in 

a CDC 6600-like processor. 

^ 

R1 «- (Y) 

R2 <- (Z) 

R3 <- R1 +f R2 
(X) <— R3 

R1 <— (B) 

R2 <- (C) 

R3 <- R1 *f R2 
(A)<—R3 

Load register R1 from memory location Y 

Load register R2 from memory location Z 

Add registers R1 and R2 

Store the result into memory location X 

Load register R1 from memory location B 

Load register R2 from memory location C 

Multiply registers R1 and R2 

Store the result into memory location A 

(a) 

time —» 

R1 <- (X) 

R2 <- (Y) 

R3 <- R1 +f R2 
(X) <— R3 

R1 <—(B) 

R2 <- (C) 

R3 <- R1 *f R2 
(A) <— R3 

FDIEEEE 

FDIEEEE 

FDI...EEE 

FDI.EEEE 

FDIEEEE 

FDIEEEE 

FDI...EEE 

FDI.EEEE 

(b) 



Figure 6. Pipelined execution of X=Y+Z and A=B*C using Tomasulo’s algo¬ 
rithm: (a) minimal register machine code; (b) timing for pipeline flow. 


6600 was pipelined only in the instruc¬ 
tion fetch/decode/issue area. It used 
parallel execution units (some dupli¬ 
cated) to get the same overlapped effect 
as pipelining. In addition, parallel units 
allowed instructions to complete out of 
order, which, in itself, is a simple form of 
dynamic scheduling. 

The CDC 6600 had instruction buffers 
for each execution unit. Instructions 


were issued regardless of whether regis¬ 
ter input data were available (the execu¬ 
tion unit itself had to be available, how¬ 
ever). The instruction’s control informa¬ 
tion could then wait in a buffer for its 
data to be produced by other instruc¬ 
tions. In this way, instructions to differ¬ 
ent units could issue and begin execution 
out of the original program order. 

To control the correct routing of data 


between execution units and registers, 
the CDC 6600 used a centralized control 
unit known as the scoreboard. The score- 
board kept track of the registers needed 
by instructions waiting for the various 
functional units. When all the registers 
had valid data, the scoreboard issued a 
series of “go” signals to cause the data 
to be read from the register file, to send 
data to the correct functional unit, and 
to start the unit’s execution. Similarly, 
when a unit was about to finish execu¬ 
tion, it signaled the scoreboard. When 
the appropriate result bus was available, 
the scoreboard sent a Y “go” signal to the 
unit, and it delivered its result to the 
register file. 

The original CDC 6600 scoreboard 
was a rather complicated control unit. In 
recent years, the term “scoreboard” has 
taken on a generic meaning: any con¬ 
trol logic that handles register and result 
bus reservations, including methods that 
are not as sophisticated as the 6600’s 
scoreboard. 

Figure 5 illustrates the example of 
Figure 2 executed with a pipeline using 
scoreboard issue logic similar to that 
used in the CDC 6600. The pipeline la¬ 
tencies are the same as those in previous 
examples. The add instruction is issued 
to its functional unit before its registers 
are ready. It then waits for its input 
register operands. The scoreboard routes 
the register values to the adder unit when 
they become available. In the meantime, 
the issue stage of the pipeline is not 
blocked, so other instructions can bypass 
the blocked add. Performance is im¬ 
proved in a way similar to the static 
scheduling illustrated in Figure 3. Here, 
it takes 13 clock periods to perform the 
required operations. 

Developed independently, and at 
roughly the same time as the CDC 6600, 
the IBM 360/91 floating-point unit 6 used 
a similar but more elaborate method of 
dynamically issuing floating-point in¬ 
structions. Instructions were issued to 
reservation stations at the inputs of the 
floating-point units. The reservation 
stations held not only control informa¬ 
tion, but also operand data. The operands 
were given tags that associated the data 
buffers in the reservation stations with 
functional units that would supply the 
data. The data would then be automati¬ 
cally routed via a common data bus to the 
appropriate reservation stations as they 
became available. Any instruction in a 
reservation station that had received all 
its input operands was free to issue. 
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Tomasulo’s algorithm, 6 used in the 
IBM 360/91, differed from the CDC 6600 
method in two important ways: 

(1) There were multiple reservation 
stations at each unit so that more than 
one instruction could be waiting for 
operands. The first one with all its input 
operands could proceed ahead of the 
others. 

(2) The use of tags, rather than regis¬ 
ter designators, allowed a form of dy¬ 
namic register reallocation, as well as 
instruction reordering. This feature was 
particularly important in the 360/91 
because the IBM 360 architecture had 
only four floating-point registers. 

Figure 6 shows the example of Figure 
2 with a minimal register allocation. The 
pipeline timing with Tomasulo’s algo¬ 
rithm appears in Figure 6b. Here, the 
timing is essentially the same as with the 
CDC 6600 scoreboard in Figure 5. Note, 
however, that the registers are automati¬ 
cally reassigned by the hardware. If the 
CDC 6600 were given the same code as 
in Figure 6, its timing would be similar to 
the slower timing shown in Figure 2 
because it would be unable to reassign 
registers “on-the-fly” as the 360/91 
does. 

Control dependencies. It may appear 
from the previous examples that, while 
the dynamic scheduling methods are very 
clever, a compiler could be used to ar¬ 
range the code as well as the hardware 
can (see Figure 3). One need only con¬ 
sider programs containing conditional 
branches, especially loops, to see that 
this is not the case. 

For static code scheduling, instruction 
sequences are often divided into basic 
blocks. A basic bloik is a sequence of 
code that can only be entered at the top 
and exited at the bottom. Conditional 
branches and conditional branch targets 
typically delineate basic blocks. To 
phrase it differently, control dependen¬ 
cies break programs into basic blocks. 
Dynamic scheduling allows instruction 
reordering beyond machine-code-level 
basic-block boundaries. This ability to 
schedule past control dependencies is 
demonstrated in later examples. 

Some advanced static scheduling 
methods are also directed at minimizing 
the effects of control dependencies. Loop 
unrolling and vectorizing start with high- 
level language basic blocks and produce 
machine-code-level basic blocks con¬ 


taining more operations. Performance is 
improved by reducing the number of 
control dependencies, but static schedul¬ 
ing still cannot look beyond the larger 
machine-code-level blocks. Dynamic 
scheduling can be used in conjunction 
with loop unrolling and vectorizing to 
further enhance performance by looking 
beyond the remaining control dependen¬ 
cies. 

Trace scheduling 7 is based on stati¬ 
cally predicting conditional branch out¬ 
comes. These predictions are based on 
compile-time information deduced from 
the source code or from compiler direc¬ 
tives. Instructions can then be reordered 
around control dependencies, but in¬ 
structions must also be inserted to 
“undo” any mistaken static branch pre¬ 
dictions. Incorrect branch predictions 
result in: 

(1) instructions executed that should 
not be, 

(2) additional instructions to undo the 
mistakes, and 

(3) execution of the correct instruc¬ 
tions that should have been done in 
the first place. 

With dynamic resolution of control de¬ 
pendencies, there are no mistakes, and 
no “undoing” is necessary. 

Some types of control constructs in¬ 
herently make certain static scheduling 
techniques extremely difficult. For ex¬ 
ample, “while” loops (in Fortran, Do 
loops with early exit conditions) severely 
restrict loop unrolling and vectorizing 
techniques because the exact number of 
loop iterations is only discovered at the 
time the loop is completed. 

As the following example illustrates, 
however, there are other advantages to 
dynamic resolution of control dependen¬ 
cies associated with ordinary Fortran Do 
loops. Figure 7 shows a Fortran loop and 
a compilation into machine instructions. 
The loop code has been statically sched¬ 
uled. Its execution for two iterations on a 
standard pipelined machine is shown in 
Figure 7c (left pipeline flow), and its 
execution with a Tomasulo-like dynamic 
hardware scheduler is shown in Figure 7c 
(right pipeline flow). 

Performance with the dynamic sched¬ 
uling algorithm is improved because the 
conditional branch at the end of the loop 
issues and executes before some of the 
preceding instructions have begun exe¬ 
cution. After the conditional branch is 
out of the way, instructions following the 


branch instruction can also be fetched 
and executed before all the instructions 
from the previous basic block(s) have 
executed. 

Note that, in the above example, nc 
special techniques are used to improve 
the performance of the conditional 
branch instruction. That is, there is nc 
branch prediction or delayed branching 
Only after the branch is executed car 
instruction fetching of the target instruc¬ 
tion begin. Dynamic scheduling reduces 
the delay between the branch and preced¬ 
ing instructions. Therefore, performance 
improvements for conditional branches 
accrue regardless of whether a particular 
branch is taken or not. More advanced 
branching methods tend to improve per¬ 
formance after the branch execution by 
reducing the hole in the pipeline between 
the branch and the following instruction. 
Consequently, special branching tech¬ 
niques can be successfully used to sup¬ 
plement a dynamic scheduling algo¬ 
rithm. 

Quantitatively, with static scheduling 
only, each loop iteration in Figure 7 
executes in 18 clock periods. With dy¬ 
namic scheduling it takes only 11 clock 
periods. This is an improvement of about 
60 percent. A more complete perform¬ 
ance comparison can be found in Weiss 
and Smith, 8 where the Cray-1 architec¬ 
ture is used as a common base for com¬ 
paring various instruction issue meth¬ 
ods, including Tomasulo’s algorithm. 
Instructions are statically scheduled 
prior to the performance analysis, and 
Tomasulo’s algorithm is shown to pro¬ 
vide a 60-percent performance improve¬ 
ment beyond that provided by static 
scheduling. 

Data dependencies. Techniques (both 
static and dynamic) that reduce the per¬ 
formance impact of control dependen¬ 
cies tend to expose data dependencies as 
the next major performance obstacle. 

(1) Dynamic scheduling around con¬ 
trol dependencies causes instructions in 
the basic block following a branch to be 
eligible for issue and execution before 
all the instructions in the previous block 
have finished. Instructions from the two 
different basic blocks may have data 
dependencies that a static scheduler 
cannot resolve. 

(2) Static scheduling methods that 
increase basic block size, such as trace 
scheduling and loop unrolling, increase 
the scheduling possibilities within the 
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(a) 


Do 1 I = 1,100 
1 A(I) = B(I) + C(I)*D(I) 


R1 4- 100 
R2 4- 1 

loop: R3 4- (C + R2) 
R4 <— (D + R2) 
R5 4- (B + R2) 
R6 4- R3 *f R4 
R7 4- R6 +f R5 
(A + R2) 4- R7 
R2 4— R2 + 1 
Br loop; R2 < R1 


(b) 


static scheduling only_dynamic scheduling 


R3 4- (C + R2) 

FDIEEEE 

FDIEEEE 

•* 

R4 4- (D + R2) 

FDIEEEE 

FDIEEEE 


R5 4- (B + R2) 

FDIEEEE 

FDIEEEE 


R6 4- R3 *f R4 

FD..IEEE 

FDI..EEE 


R7 4- R6 +f R5 

F..D..IEEE 

FDI 

EEE 

(A + R2) 4- R7 

F..D..IEEEE 

FDI... 

...EEEE 

R2 4- R2 + 1 

F..DIE 

FDIE 


Br loop; R2 < R1 

FDIE 

FDIE 


R3 4- (C + R2) 

FDIEEEE 


FDIEEEE 

R4 4- (D + R2) 

FDIEEEE 


FDIEEEE 

R5 4- (B + R2) 

FDIEEEE 


FDIEEEE 

R6 4- R3 *f R4 

FD..IEEE 


FDI..EEE 

R7 4- R6 +f R5 

F..D..IEEE 


FDI....EEE 

(A + R2) 4- R7 

F..D..IEEEE 


FDI.EEEI 

R2 4- R2 + 1 

F..DIE 


FDIE 

Br loop; R2 < R1 

FDIE 


FDIE 


(c) 


without dynamic instruction scheduling: (a) Fortran loop; (b) machine in- 


Figure 7. Loop execution with and 
structions; (c) pipeline flows. 


basic block. Indeed, this is a major justi¬ 
fication for using such methods. In the 
process, however, the number and vari¬ 
ety of data dependencies is increased as 
well. 

Data dependencies may involve data 
held either in registers or memory. There 
are three varieties of data dependencies 9 : 

(1) flow dependencies, when a result 
operand of one instruction is used 
as a source operand for a subse¬ 
quent one, 

(2) output dependencies, when a re¬ 
sult operand of one instruction is 
also used as a result operand for a 
subsequent one, and 


(3) antidependencies, when a source 
operand of one instruction is used 
as a result operand for a subse¬ 
quent one. 

All three types of data dependencies 
can occur for either register data or 
memory data. Flow dependencies are 
inherent in the algorithm and cannot be 
avoided. Within a basic block, output 
and antidependencies involving regis¬ 
ters can be avoided by static methods, 
specifically by reallocating registers 
(assuming that enough registers are 
available). However, dynamic schedul¬ 
ing of branch instructions may result in 
situations where output and antidepen¬ 
dencies involving register instructions in 


different basic blocks must be resolved. 
For example, in Figure 7, one can con¬ 
ceive of dynamic issuing methods where 
the load from memory into R3 is ready to 
issue for the second loop iteration before 
the instruction using the old value of R3 
(i.e., R6 = R3 *f R4) has issued in the first 
loop iteration. (While this may at first 
seem farfetched, the dynamic issuing 
method used by the ZS-1 frequently 
causes such a situation.) Dynamic regis¬ 
ter reallocation such as that provided by 
Tomasulo’s algorithm can effectively 
deal with such situations. 

Probably more difficult to deal with 
than dependencies involving registers 
are memory data dependencies. All three 
forms of data dependencies that can 
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occur with registers can also occur with 
memory data. For example, a load in¬ 
struction following a store to the same 
memory address is a flow dependence, 
and the load may not be reordered ahead 
of the store instruction. On the other 
hand, if the load and store are to different 
addresses, there is no problem with reor¬ 
dering them. 

Load and store instructions to scalar 
variables produce dependencies that are 
relatively simple to resolve. Further¬ 
more, data dependencies involving sca¬ 
lars can often be removed by optimizing 
compilers. 

Memory dependencies involving ar¬ 
rays and other data structures are much 
more difficult to schedule. The major 
problem with scheduling such memory 
dependencies lies in detecting them. 
Accesses involving arrays and other data 
structures use index values that can 
change at runtime, so complete informa¬ 
tion regarding the index values may be 
difficult or impossible for the compiler 
to discern. This is because the only ad¬ 
dress information available to the com¬ 
piler is in symbolic form (such as array 
subscript expressions expressed in a 
high-level language). 

Trace scheduling and loop unrolling 
combine high-level language basic 
blocks into larger machine-language 
ones. Significant performance advan¬ 
tages accrue if operations from the origi¬ 
nal basic blocks can be “blended” to¬ 
gether as the instructions are scheduled. 
A good schedule tends to have load in¬ 
structions near the top of a basic block 
with functional operations (adds and 
multiplies) in the middle and stores near 
the bottom. To aajiieve this with trace 
scheduling or loop unrolling, load in¬ 
structions must often be scheduled ahead 
of stores belonging to different loop it¬ 
erations. Consequently, the ability to 
determine data dependencies involving 
loads and stores from different HLL 
basic blocks is of critical importance. In 
the trace scheduling method, this proc¬ 
ess, known as memory disambiguation, 10 
is a very important component. Memory 
disambiguation manipulates array sub¬ 
script expressions in the form of systems 
of integer equations and inequalities to 
determine if load and store addresses to 
the same array can ever coincide in such 
a way that it is unsafe to interchange the 
load and store instructions. 

Vectorizing compilers also concen¬ 
trate on this kind of dependence, using 
very similar methods." In fact, resolving 


memory data dependencies involving 
array references is a primary feature of 
vectorizing methods. Because of the 
excellent literature available on vec¬ 
torizing compilers, the remaining dis¬ 
cussion on memory data dependencies is 
phrased in terms of vectorizing com- 

If the loop statement A(I) = A(J) + C(7) 
is vectorized, 

(1) the elements of A(I) are loaded as 
a vector, 

(2) the elements of C(J) are loaded as 
a vector, 

(3) there is a vector add of A(l) and 
C(I), and 

(4) A(f) is stored as a vector. 

The vector load of the A(f) followed 
later by the vector store amounts to a 
massive reordering of the loads and 
stores. That is, loads from A(f) for later 
loop iterations are allowed to pass stores 
for earlier iterations. The loop A (I) = A(l- 
1) + C(I) cannot be vectorized as just 
described, however, because the loads of 
A(I- 1) involve values just computed 
during the previous loop iteration. (Some 
simple linear recurrences may vectorize 
on certain computers that have special 
recurrence instructions. Throughout, 
this article uses simple examples for il¬ 
lustrative purposes; more complex linear 
and nonlinear recurrences could just as 
easily be used to prove the point.) 

In two important classes of problems 
the static data dependence analysis done 
by compilers cannot achieve perform¬ 
ance as high as dynamic runtime analy¬ 
sis. The first class involves analyses of 
such complexity that the compiler can¬ 
not safely determine if the subscripts are 
independent. These are referred to as 
ambiguous subscripts. The second class 
consists of code that has true load/store 
conflicts, but only for a few iterations of 
a loop. 

An example of ambiguous subscripts 
is shown below: 

NL1=1 
NL2=2 
Do 1 1=1,N 
Do 2 J=1,N 

2 A(J,NL1 )=A(J-1 ,NL2)+B(J) 

NTEMP=NL1 
NL1=NL2 

1 NL2=NTEMP 

In the above example, the array A is split 
into two halves; old values in one half are 


used to compute new values in the other. 
When this process is finished, the two 
halves are switched (by interchanging 
NL\ and NL2). This kind of construct can 
be found in many Fortran programs. In 
fact, the original program from which 
Lawrence Livermore Kernel 8" was ex¬ 
tracted used this kind of technique. A 
vectorizing compiler must determine 
that NL 1 is never equal to NL2 to vec¬ 
torize the loop. It is doubtful that any 
current vectorizing compiler has this 
capability. (However, a compiler might 
compile the example code as both vector 
and scalar and use a runtime test when¬ 
ever the loop is encountered to determine 
which version should be used.) In 
general, NL 1 and NL2 could be arbitrar¬ 
ily complex functions of any number of 
variables. This suggests the theoretical 
undecidability of vectorizable loops. 

As another example, consider array 
references that frequently occur when 
handling sparse matrices. For example, 
A(MAP(P>) = A(MAP(J)) + B(I), where 
MAP is an integer array of indices. This 
code can be vectorized (with vector 
gather/scatter instructions) if the com¬ 
piler can determine that none of the 
MAPiJ) are equal. In most cases this is 
beyond a vectorizing compiler’s capa¬ 
bilities. 

As mentioned above, the second im¬ 
portant class of problems where static 
analysis is inferior to dynamic analysis 
occurs when loops have true data de¬ 
pendencies, but for relatively few of the 
loop iterations. For example, consider 
the following nested loop: 

DO 1 J=1,N 

DO 1 1=1,N 

1 X(I) = X(J) + Y(D 

For a particular execution of the inner 
loop, the value of X(J) changes partway 
through, when I=J. The store into X(I) 
when I=J must follow all the loads of 
X(J) for preceding inner loop iterations. 
This store must precede all subsequent 
loads of X(J). 

Another example is the case where 
subscripted subscripts are used; for ex¬ 
ample, the inner loop statement X{M(K)) 
= X(N(K)) + W(K), where M and N have 
a small nonempty intersection. In this 
case, many, but not all, of the loads may 
pass stores. (The ones that may not pass 
occur when M(/l) = N(I2) for 12 < 71.) 

Dynamic scheduling: stunt boxes. 

The IBM 360/91 memory system 12 al- 
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DO 1 J=1,N 
DO 1 1=1,N 
X(I) = X(J) + Y(I) 


(a) 


R3 4- (Rl) 

R4 4— (Y + R2) 

R6 4- (Y+l + R2) 
R5 4- R3 +f R4 
(X + R2) 4— R5 
R7 4- (Rl) 

R8 4- R6 +f R7 
(X+l + R2) 4- R8 
R2 4— R2 + 1 
Br loop; R2 < Rl 
R3 4- (Rl) 

R4 4- (Y + R2) 

R6 4- (Y+l + R2) 
R5 4- R3 +f R4 
(X + R2) 4- R5 
R7 4— (Rl) 

R8 <- R6 +f R7 
(X+l + R2) 4- R8 
R2 4- R2 + 1 
Br loop; R2 < Rl 


FDIEEEE 
FDIEEEE 
FDIEEEE 
FDI..EEE 


FDI....EEEE 
FDI....EEEE 

FDI.EEE 

FDI.EEEE 


FDIE 

FDIE 


FDI....EEEE 
FDI....EEEE 
FDI....EEEE 


FDI.EEE 

FDI.EEEE 

FDI.EEEE 

FDI.EEE 

FDI.EEEE 


FDIE 
' FDIE 


(b) 


no memory conflicts_with memory conflict 


R3 4- (Rl) 

FDIEEEE 

FDIEEEE 


R4 4- (Y + R2) 

FDIEEEE 

FDIEEEE 


R6 4- (Y+l + R2) 

FDIEEEE 

FDIEEEE 


R5 4- R3 +f R4 

FDI..EEE 

FDI..EEE 


(X + R2) 4— R5 

FDI....EEEE 

FDI.... 

EEEE 

R7 4- (Rl) 

FDIEEEE 

FDI... 

■ EEEE 

R8 4- R6 +f R7 

FDI...EEE 

FDI. . 

.EEE 

(X+l + R2) 4- R8 

FDI.EEEE 

FDI. 

.EEEE 

R2 4— R2 + 1 

FDIE 

FDIE 

Br loop; R2 < Rl 

FDIE 

FDIE 

R3 4- (Rl) 

FDIEEEE 


FDIEEEE 

R4 4- (Y + R2) 

FDIEEEE 


FDIEEEE 

R6 4- (Y+l + R2) 

FDIEEEE 


FDIEEEE 

R5 4- R3 +f R4 

FDI..EEE 


FDI..EEE 

(X + R2) 4- R5 

FDI....EEEE 


FDI....EEEE 

R7 4- (Rl) 

FDIEEEE 


FDIEEEE 

R8 4- R6 +f R7 

FDI...EEE 


FDI...EEE 

(X+l + R2) 4- R8 

FDI.EEEE 


FDI.EEEE 

R2 4— R2 + 1 

FDIE 


FDIE 

Br loop; R2 < Rl 

FDIE 


FDIE 


(c) 


Figure 8. The effects of load/store reordering: (a) a nonvectorizable loop with a memory hazard; (b) pipeline execu¬ 
tion without dynamic memory reordering; (c) pipeline execution with dynamic memory reordering. 
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lowed load instructions to pass store 
instructions after they had been issued. 
The memory system allowed the dy¬ 
namic reordering of loads and stores as 
long as a load or a store did not pass a 
store to the same address. Store instruc¬ 
tions could issue before their data were 
actually ready. There was a queue for 
store instructions waiting for data. Load 
instructions entering the memory system 
had their addresses compared with the 
waiting stores. If there were no matches, 
the loads were allowed to pass the wait¬ 
ing stores. If a load matched a store 
address, it was held in a buffer. When the 
store data became available, they were 
automatically bypassed to the waiting 
load as well as being stored to memory. 

The CDC 6600 memory system was 
simpler than in the IBM 360/91 and al¬ 
lowed some limited reordering of mem¬ 
ory references to increase memory 
throughput in a memory system that used 
no cache and had a relatively slow inter¬ 
leaved main memory. In the CDC 6600, 
the unit used for holding memory refer¬ 
ences while they were waiting for mem¬ 
ory was called the stunt box. The CDC 
6600 stunt box did not actually allow 
loads to pass waiting stores, but just as 
the term “scoreboard” has taken on a 
more general meaning than the way it 
was used in the 6600, the term “stunt 
box” has come to mean any device that 
allows reordering of memory references 
in the memory system. 

Figure 8a shows a Fortran loop, un¬ 
rolled twice, that has a memory data 
dependence that inhibits vectorization. 
Because of this, the compiler is restricted 
from moving certain loads above stores 
that may potentially be to the same ad¬ 
dress. Figure 8b shows pipeline usage 
with dynamic scheduling but with no 
provision for loads to pass stores via a 
stunt box. Figure 8c shows pipeline us¬ 
age with dynamic scheduling and a 
memory stunt box. The left pipeline flow 
is for a sequence of code where /</ so 
there are no dependencies involving X(J) 
and X(J). The right pipeline flow in¬ 
cludes the case where / “passes” J so 
that there is temporarily a memory haz¬ 
ard preventing a load from X(J) from 
passing a store to X(I) when I=J. This 
results in a temporary glitch in the execu¬ 
tion of memory instructions, but there is 
no overall time penalty as the code se¬ 
quence continues past the point where 
I=J. By inspecting the timing diagrams, 
the pipeline without dynamic load/store 
reordering can execute one loop iteration 


(two iterations in the original rolled loop) 
every 17 clock periods. With dynamic 
load/store reordering, it executes an it¬ 
eration every 13 clock periods. Without 
any dynamic scheduling at all, each loop 
iteration takes 25 clock periods (this case 
is not illustrated). Using full dynamic 
scheduling results in an almost two- 
times performance improvement over 
static scheduling alone. 

The viability of 
dynamic scheduling 

As pointed out, dynamic scheduling 
was used in large-scale computers in the 
1960s and has not been used to any ap¬ 
preciable extent since. One can only 
speculate about the reasons for abandon¬ 
ment of dynamic scheduling in produc¬ 
tion high-performance machines. Fol¬ 
lowing are some of the possible reasons: 

(1) Increased difficulty in hardware 
debugging: a hardware failure can cause 
errors that are highly dependent on the 
order of instruction issuing for many 
clock periods prior to the actual detec¬ 
tion of the error. This makes error repro¬ 
ducibility difficult. The fault diagnosis 
problem was compounded in the IBM 
360/91 and CDC 6600 because discrete 
logic was used, and diagnostic resolution 
had to be very fine. 

(2) Longer clock period: dynamic in¬ 
struction issuing can lead to more com¬ 
plex control hardware. This carries with 
it potentially longer control paths and a 
longer clock period. 

(3) Advances in compiler develop¬ 
ment: initially, dynamic scheduling per¬ 
mitted simple compilers that required 
relatively little static scheduling capa¬ 
bility. However, improved compilers with 
better register allocation and scheduling 
could realize some (but certainly not all) 
of the benefits of dynamic issuing. 

Why consider dynamic scheduling to¬ 
day, when it was passed by years ago? 
First, very large scale integration parts 
and extensive use of simulation in to¬ 
day’s computers alleviate many of the 
debugging and diagnosis problems pres¬ 
ent 20 years ago. Simulation can be used 
to find design errors, and hardware faults 
need only be located to within a (large) 
replaceable unit. That is, if a fault is 
detected in a CPU’s instruction issue 
logic, the entire CPU, or at least a large 
part of it, can be replaced; there is no 


need for extensive and detailed fault 
location methods. 

Second, it is possible to use methods 
that selectively limit the generality of 
dynamic scheduling so that significant 
performance benefits can be realized 
while keeping the control logic simpler 
than in the CDC 6600 and IBM 360/91. 
Techniques of this type have been suc¬ 
cessfully used in the ZS-1 and are de¬ 
scribed in later sections. 

Third, both compiler scheduling and 
processor design are much more mature, 
and most of the big performance gains in 
these areas have probably been made. 
Consequently, the gains achievable by 
dynamic scheduling may appear more 
attractive today than they did 20 years 
ago. 

The ZS-1 

The Astronautics ZS-1 is a recently 
developed, high-speed computer system 
targeted at scientific and engineering 
applications. The ZS-1 central processor 
is constructed of transistor-transistor 
logic-based technology and has no vec¬ 
tor instructions, but makes extensive use 
of dynamic instruction scheduling and 
pipelining to achieve one-third the per¬ 
formance of a Cray X-MP1. 

A block diagram of a ZS-1 system is 
shown in Figure 9. The ZS-1 is divided 
into four major subsystems: the central 
processor, the memory system, the I/O 
system, and the interconnection network. 
In its maximum configuration, the ZS-1 
contains one gigabyte of central mem¬ 
ory, and an I/O system consisting of up to 
32 input-output processors. Unix is the 
primary operating system. 

The ZS-1 uses a decoupled architec¬ 
ture 13 that employs two instruction pipe¬ 
lines to issue up to two instructions per 
clock period. One of the instruction 
streams performs the bulk of fixed-point 
and memory addressing operations, 
while the other performs floating-point 
calculations. 

To support the two instruction 
streams, the decoupled architecture of 
the ZS-1 provides two sets of operating 
registers. A set of thirty-one 32-bit A 
registers is used for all memory address 
computation and accessing, and a second 
set of thirty-one 64-bit X registers is 
used for all floating-point operations. 
The A and X registers provide fast tempo¬ 
rary storage for 32-bit integers and 64- 
bit floating-point numbers, respectively. 
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Figure 9. Overall diagram of the ZS-1 system. 


1 

1 


Do 10 I = 1, 100 

10 

(a) 

A(I) = B(I)*C(I) + D(I) 


SI 

A5 <— 0 

.loop count 

S2 

A6 <— A - 8 

.load initial pointer to A 

S3 

A7 4— B - 8 

.load initial pointer to B 

S4 

A8 4— C - 8 

.load initial pointer to C 

S5 

A9 <— D - 8 

.load initial pointer to D 

S6 

loop: A5 4— A5 + 1 

.increment A5 

S7 

B, A0 4- (A5 == 100) 

.compare =, set Branch Flag 

S8 

XLQ 4- (A7 = A7 + 8) 

.load next element of B 

S9 

XLQ 4- (A8 = A8 + 8) 

.load next element of C 

S10 

XLQ 4- (A9 = A9 + 8) 

.load next element of D 

Sll 

X2 4- XLQ 

.copy B element into X2 

S12 

X3 4- X2 *f XLQ 

.multiply B and C 

S13 

XSQ 4- XLQ +f X3 

.add D; result to XSQ 

S14 

(A6 <- A6 + 8) = XSQ 

.store result into A 

S15 

Br loop; B==0 

.branch on false to “loop” 

(b) 




Figure 10. A Fortran loop and its ZS-1 compilation: (a) Fortran source; 
(b) machine language version of the loop. 


A distinctive feature of the ZS-1 is the 
use of architectural queues for communi¬ 
cation with main memory. There are two 
sets of queues. One set consists of a 15- 
element A load queue (ALQ) and a 7- 
element A store queue (ASQ). These A 
queues are used in conjunction with the 
32-bit A registers. The other set of queues 
consists of a 15-element X load queue 
(XLQ) and a 7-element X store queue 
(XSQ). These X queues are used in con¬ 
junction with the 64-bit X registers. 

Instructions. Instruction formats are 
reminiscent of those used in the CDC 
6600/7600 and Cray-1. There is an op¬ 
code, and operands specified 1>y i, j, and 
k fields. The j and k fields typically 
specify input operands and the i field 
specifies the result. The i, j, and k oper¬ 
ands may be either general-purpose reg¬ 
isters or queues. A designator of 31 in the 
j or k field indicates that the first element 
of the load queue is used as a source 
operand. A designator of 31 in the i field 
indicates that the result is placed into the 
store queue. In this way, queue operands 
can be easily intermixed with register 
operands in all instruction types. The 
opcode determines whether A registers 
and queues or X registers and queues are 
to be operated upon. 

The ZS-1 architecture is best under¬ 
stood by examining a sequence of ma¬ 
chine code. Figure 10a contains a simple 
Fortran loop, and Figure 10b contains a 
compilation into ZS-1 machine instruc¬ 
tions. The instruction 51 initializes 
fixed-point register A5, which is used as 
the loop counter. Then instructions 52 
through 55 initialize A6 through A9 to 
point to the arrays accessed in the loop. 
The pointers are offset by -8 because 
byte addressing is used, and the load and 
store instructions use pre-autoincre¬ 
menting. 

In the loop body, instructions 56 and 
57 increment the loop counter and test it 
to see if it has reached the upper limit. 
The test is done by a compare instruc¬ 
tion, which generates a Fortran Boolean 
result that is placed in A0 (because A0 is 
defined to always hold constant 0, this is 
equivalent to discarding it), and it also 
sets the architectural branch flag, B, to 
the result of the comparison. The branch 
flag will be tested by the conditional 
branch instruction that terminates the 
loop. 

Instructions 58 through 510 load the 
elements from arrays B, C, and D. These 
memory operands are automatically 
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Figure 11. The ZS-1 processor pipelines. 


placed in the XLQ. Because the destina¬ 
tion of the load instructions are queues 
implied by the opcode, the i field of load 
and store instructions may be used to 
specify a result register for the effective 
address add. This makes autoincre¬ 
menting memory operations particularly 
easy to implement. 

Then instructions Sll through SI3 
copy the memory data from the XLQ and 
perform the required floating-point op¬ 
erations. Tltese are generic floating¬ 
point instructions with register designa¬ 
tor 31 used wherever there is a queue 
operand. The floating-point add is of 
particular interest because it not only 
uses the XLQ as its j operand, but it also 
uses the XSQ for its result. The store 
instruction, SI4, generates the store 
address in array A. 

Decoupled 

implementation 

A simplified block diagram of the ZS- 
1 CPU pipelines is shown in Figure 11. 
The pipeline segments include an in¬ 
struction fetch stage where instruction 
words are read from a 16-kilobyte in¬ 


struction cache. An instruction word may 
contain either one 64-bit instruction 
(used for conditional branches and loads 
and stores with direct addressing) or two 
32-bit instructions (by far the most 
common case). The next pipeline seg¬ 
ment is the “splitter” stage, where in¬ 
struction words are split into instructions 
and sent to the two instruction pipelines. 
In one cycle, the instruction word is 
examined by the A instruction pipeline 
and the X instruction pipeline to see 
whether it contains one or two instruc¬ 
tions and to determine whether the in¬ 
structions are: 

(1) X unit instructions, 

(2) A unit instructions, 

(3) branch instructions or system call/ 
return instructions. 

Branch and system call/retum instruc¬ 
tions are held and executed in the splitter 
stage. Instructions belonging to the first 
two classes are sent to an instruction 
buffer at the beginning of the appropriate 
instruction pipeline. Up to two instruc¬ 
tions are forwarded to the instruction 
pipelines per clock period. 

The instruction buffer in the X instruc¬ 


tion pipeline can hold 24 instructions. 
The buffer in the A instruction pipeline is 
four instructions deep and can be by¬ 
passed. The very deep X instruction 
buffer allows the A instruction pipeline 
to issue many instructions in advance of 
the X instruction pipeline. The A instruc¬ 
tion buffering is intended to reduce 
blockages of the splitter. The bypass 
allows instructions to move quickly up 
the A pipeline when it is empty; for 
example, following some branches. 

In the instruction pipelines, pipeline 
segments are: 

(1) the buffer stage where instructions 
are read from the instruction buff¬ 
ers, 

(2) the decode stage where instruc¬ 
tions are decoded, and 

(3) the issue stage where instructions 
are sent to functional units for 
execution. 

At the issue stage a simple Cray-1-like 
issuing method allows instructions to 
begin execution in strict program se¬ 
quence. For example, if an instruction 
uses the result of a previously issued, but 
unfinished, instruction, it waits at the 


July 1989 


31 
































































1: A5 <— A5 + 1 

FSdie 

2: B, AO <- (A5 == 100) 

FSbdie 

3: XLQ <- (A7 = A7 + 8) 

FSbdieeee 

4: XLQ <- (A8 = A8 + 8) 

FS.bdieeee 

5: XLQ <- (A9 = A9 + 8) 

FS.bdieeee 

6: X2 <- XLQ 

FSBD...IE 

7: X3 X2 *f XLQ 

FSB...DIEEE 

8: XSQ <—XLQ+f X3 

FS....BD..IEEE 

9: (A6 <- A6 + 8) = XSQ 

FSbdi.eeee 

10: Br loop;B==0 

FS 

11: A5 <— A5 + 1 

FSdie 

12: B, A0 <- (A5 == 100) 

FSbdie 

13: XLQ <- (A7 = A7 + 8) 

FSbdieeee 

14: XLQ <- (A8 = A8 + 8) 

FS.bdieeee 

15: XLQ <- (A9 = A9 + 8) 

FS.bdieeee 

16: X2 <— XLQ 

FSBD...IE 

17: X3 <r- X2 *f XLQ 

FSB...DIEEE 

18: XSQ <— XLQ +f X3 

FS.B...D..IE 

19: (A6 <- A6 + 8) = XSQ 

FSbdi.eeee 

20: Br loop;B==0 

FS 


Figure 12. The processing of two iterations of the loop in Figure 10. 


issue register until the previous instruc¬ 
tion completes. 

At the time an instruction is issued 
from one of the pipelines, operand data 
are read from the appropriate register 
files and/or queues. After issue, the in¬ 
struction begins execution in one of the 
parallel functional units. The primary 
functional units for the fixed-point A 
instructions are: a shifter, an integer 
adder/logical unit, and an integer multi¬ 
plier/divider. The primary functional 
units for the floating-point X instruc¬ 
tions are: an X logical unit, a floating¬ 
point adder, a floating-point multiplier, 
and a floating-point divider. Data can be 
copied between A and X registers via the 
copy unit. 

The ZS-1 uses several dynamic sched¬ 
uling techniques: 

(1) The architectural instruction 
stream is split in two, with each resulting 
stream proceeding at its own speed. This 
not only permits the ZS-1 to sustain an 
instruction issue rate of up to two in¬ 
structions per clock period, but it allows 
the memory access instructions to dy¬ 
namically schedule ahead of the float¬ 
ing-point instructions. In addition, the 
Scoreboard issue logic at the end of each 


of the instruction pipelines remains as 
simple as in the Cray-1; no instruction 
reordering is done within a single pipe¬ 
line. 

(2) Branch instructions are held and 
executed at the splitter. This is accom¬ 
plished by decomposing branch opera¬ 
tions into their two fundamental compo¬ 
nents: comparing register values and 
transferring control. Compare instruc¬ 
tions are detected in the splitter and set 
the branch flag to “busy” as they pass 
through. If a branch instruction encoun¬ 
ters a “busy” branch flag, it waits in the 
splitter until the flag is set by the com¬ 
pare instruction. Compare instructions 
are subsequently issued from the appro¬ 
priate instruction pipeline, depending on 
whether fixed- or floating-point data are 
tested. A comparison sets the branch flag 
when it completes. Consequently, branch 
instructions do not directly read register 
values, they simply test the branch flag. 
This mechanism allows branches to be 
executed dynamically ahead of instruc¬ 
tions that precede them in the instruction 
stream. Furthermore, executing 
branches very early in the pipeline re¬ 
duces, and in some cases eliminates, any 
resulting “hole” in the pipeline. 

(3) Using queues for memory oper¬ 


ands provides an elastic way of joining 
the memory access and floating-point 
functions. This elasticity allows the 
memory access function to schedule it¬ 
self dynamically ahead of the floating¬ 
point operations. This can also be viewed 
as a way of achieving dynamic register 
allocation. That is, each load or store 
instruction dynamically allocates a new 
value of “register” 31. 

(4) Store instructions merely generate 
store addresses; they do not wait for the 
store data before issuing. In the memory 
system is a stunt box containing two 
queues, one for load addresses and the 
other for store addresses. Store addresses 
wait in their queue until a corresponding 
data item appears in a store data queue 
(one for fixed-point data, one for float¬ 
ing-point). Load addresses may pass 
store instructions that are waiting for 
their data. Memory hazards are checked 
by comparing load and store addresses so 
that loads do not pass stores to the same | 

address. 

Figure 12 illustrates the processing of 
two iterations of the loop in Figure 10. 

As in earlier examples, only the instruc¬ 
tions within the loop body are shown. 

Many of the pipeline stages are the same 
as in previous examples, and there are 
two new stages. One of the new stages is 
the splitter stage, the other is the buffer 
stage at the beginning of each of the 
instruction pipelines (although the buffer 
in the fixed-point pipeline can be by¬ 
passed). Because there are actually two 
distinct instruction pipelines following 
the splitter, for all stages after the split¬ 
ter lowercase letters are used to denote 
fixed-point instructions, and uppercase 
letters are used for floating-point in¬ 
structions. Pipeline lengths are the same 
as in the previous examples to more 
clearly demonstrate the principles at 
work. To summarize, the letters labeling 
pipeline stages have the following mean- < 
ings: 

F denotes the instruction is in the fetch 
stage, 

S indicates the instruction word is 
processed at the splitter, 

B or b indicates the instruction is read 
from an instruction buffer, 

D or d indicates the instruction is 
decoded, 

/ or i indicates the instruction is issued 
for execution, 

E or e indicates the instruction is exe¬ 
cuted. 
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The first instruction (A5 = A5 + 1) is split 
at time 0, decoded at time 1 (the buffer is 
bypassed), issued at time 2, and executed 
at time 3. 

The second instruction is split at the 
same time as the first and is read from the 
buffer at time 1. Note that this second 
instruction sets the branch flag. The next 
three instructions follow a similar se¬ 
quence for processing. 

The sixth instruction is the first X 
instruction. It is split at time 2, is read 
from the X instruction buffer at time 3, 
and is decoded at time 4. It must then 
wait for data from the XLQ before 
continuing. 

The seventh and eighth instructions 
perform the required floating-point op¬ 
erations in sequence, with the eighth 
putting its result in the XSQ for storage 
to memory. 

The ninth instruction generates the 
store address for the preceding one. It is 
an A instruction that issues at time 7. It 
passes through four clock periods of 
execution while the address is generated 
and translated. It then waits while the pre¬ 
ceding floating-point addition completes. 
Then the result is stored to memory. 

The tenth and final instruction in the 
loop body is the conditional branch. It is 
detected and executed in the splitter 
stage. Note that, in this example, all but 
one of the clock periods required for the 
conditional branch are hidden; instruc¬ 
tion issuing proceeds without interrup¬ 
tion in the fixed-point pipeline. 

The second loop iteration follows the 
first in Figure 12, and all subsequent 
loop iterations are similar to it. In this 
example, steady state performance is 
determined by the rate at which the fixed- 
point operations can be issued. In cases 
where floating-point dependencies are 
more severe, steady state performance is 
determined by the floating-point pipeline. 

By extrapolating data from the dia¬ 
gram we can see that up to three itera¬ 
tions of the loop are in some phase of 
processing simultaneously. This is a 
clear example of the ability of dynamic 
scheduling to fetch and execute instruc¬ 
tions beyond basic-block boundaries. 
During many clock periods eight or more 
instructions are processed in parallel (not 
counting those blocked in the pipeline). 

The example just given is intended to 
illustrate dynamic scheduling aspects of 
the ZS-1 implementation. In fact, the ZS- 
1 compilers automatically unroll loops. 
The degree of unrolling is a function of 



A5 A5 + 1 

FSdie 

B, AO <- (A5 == 100) 

FSbdie 

XLQ 4- (Al) 

FSbdieeee 

XLQ <- (A2 + 8) 

FS.bdieeee 

XLQ <- (A2 + 8) 

FS.bdieeee 

XI <- XLQ 

FSBD...IF 

XSQ <- XI +f XLQ 

FSB. . .DIEEE 

X2 <- XLQ 

FS.,..BDIE 

(A3 + 8) e- XSQ 

FSbdi.eeee 

XLQ <- (Al) 

FS.bdieeee 

XSQ <- X2 +f XLQ 

'■ FS. . . BD . IEEE 

(A3 + 8) <- XSQ 

FS.bdi.eeee 

Br loop;B==0 

FS 

A5 <— A5 + 1 

FSdie 

B, AO <- (A5 == 100) 

FSbdie 

XLQ <- (Al) 

FSbdieeee 

XLQ <- (A2 + 8) 

FS.bdieeee 

XLQ <- (A2 + 8) 

FS;bdieeee 

XI <- XLQ 

FSBD...IE 

XSQ <- XI +f XLQ 

FSB...DIEEE 

X2 <- XLQ 

FS....BDIE 

(A3 + 8) <- XSQ 

FSbdi.eeee 

XLQ <- (Al) 

FS.bdieeee 

XSQ <- X2 +f XLQ 

FS...BD.IEEE 

(A3 + 8) <- XSQ 

FS.bdi.eeee 

Br laop;B==0 

FS 


Figure 13. ZS-1 execution of a nonvectorizable loop. 


the size of the loop; for a simple loop as 
illustrated in Figure 12, the Fortran 
compiler unrolls the loop body eight 
times. When this is done, and instruc¬ 
tions are rescheduled using the resulting 
larger basic blocks, vector levels of per¬ 
formance can be achieved. For example, 
if the loop of Figure 12 is unrolled for the 
ZS-1, a load or store instruction issues 
during 94 percent of the clock periods. In 
other words, the memory path is busy 94 
percent of the time. Many vector pro¬ 
cessors, including the Cray-1 and Cray- 
2, have their vector performance limited 
by their ability to perform only one load 
or store operation per clock period. For 
practical purposes, this is the same bot¬ 
tleneck that ultimately limits ZS-1 per¬ 
formance, and vector instructions would 
provide no significant performance 
benefit. 

On the other hand, when faced with 
loops like those in Figure 8 that do not 
vectorize, the ZS-1 can achieve vector 
performance levels. This is illustrated in 
Figure 13, where the loop is unrolled two 
times to permit comparison with the 
earlier example. 

This example illustrates the iterations 


where no memory conflict exists. When 
I=J and there is a memory conflict, a 
slight perturbation that lasts for only two 
loop iterations occurs. The delays caused 
by this perturbation are completely hid¬ 
den by the dynamic scheduling, how¬ 
ever. The total time to execute an inner 
loop in this example is nine clock peri¬ 
ods. Because this loop is not vecto- 
rizable, we saw earlier that it would take 
a static-scheduled Cray-1-like machine 
17 clock periods to execute the inner 
loop once. Note also that this example 
illustrates a situation where instruction 
issuing in the fixed-point pipeline is 
completely uninterrupted by the condi¬ 
tional branch executed at the splitter. 

ZS-1 performance 

All the examples in this article have 
used a fixed set of pipeline lengths to 
make comparisons possible. The produc¬ 
tion ZS-1 models operate at a 45-nanos¬ 
econd clock period and use VLSI float¬ 
ing-point chips that provide pipeline 
lengths of three clock periods for 64-bit 
floating-point multiplication and addi- 
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Additional reading on 
dynamic instruction scheduling 

The book by Thornton 4 describing the CDC 6600 is a classic, but unfortunately 
it is out of print. Considerable detail on the scoreboard design can be found in 
the Thornton and Cray patent, U.S. patent no. 3,346,851. The IBM 360/91 is de¬ 
scribed in a series of papers in the January 1967 issue of the IBM Journal of Re¬ 
search and Development. A recent book by Schneck 15 contains a discussion of 
several pipelined machines, including both the CDC 6600 and the IBM 360/91. 
The book by Kogge 16 Is another excellent reference. Recent research in pipe¬ 
lined computers has concentrated on static scheduling, rather than dynamic 
scheduling. A notable exception is work being undertaken by Hwu and Patt 17 that 
contains interesting enhancements to Tomasulo’s algorithm. 


tion. (The prototype systems described 
in an earlier work 14 used standard TTL- 
based floating-point units with latencies 
about twice as long. In addition, the 
production systems use a true divide 
algorithm as opposed to the reciprocal 
approximation method described in that 
work. 14 ) The memory pipeline is conser¬ 
vatively designed and consumes eight 
clock periods for data found in the 128- 
kilobyte data cache. The decision to use 
a data cache was made relatively late in 
the design process. Consequently, the 
cache was added in series with the ad¬ 
dress translation unit, with a board- 
crossing between. A more parallel ad¬ 
dress translation/cache system would 
probably have only half the latency, or 
about four clock periods. 

For performance comparisons, we use 
the 24 Livermore Kernels" because they 
are extracted from real programs and 
contain a realistic mix of both vector and 
scalar code. To summarize performance 
in millions of floating-point operations 
per second (Mflops), we use the har¬ 
monic mean, which is the total number of 
operations (scaled to be the same for 
each kernel) divided by the total time. 
For the 24 double-precision kernels, 
using the original Fortran (with no added 
compiler directives, as are often used to 
assist vector machines), the ZS-1 per¬ 
forms at 4.1 Mflops. 

The Multiflow Trace 7/200'° is con¬ 
structed of similar-speed technology 
(about 3.5 nanoseconds per gate) as the 
ZS-1 and uses state-of-the-art trace 
scheduling compiler technology. On the 
24 Livermore Kernels the Multiflow 
Trace operates at 2.3 Mflops. As a final 
comparison, the Cray X-MP can execute 
the Livermore Kernels at 12.3 Mflops." 

Of course, all the above performance 
numbers are very much a function of the 
compiler used. It is expected that later 
compiler versions for any of the ma¬ 
chines, including the ZS-1, could lead to 
improved performance. 


D ynamic instruction scheduling 
improves performance by re¬ 
solving control and data de¬ 
pendencies at runtime using real data. 

Static scheduling must rely on predic¬ 
tions or worst-case assumptions made at 
compile time. Consequently, there will 
always be situations where runtime sched¬ 
uling can outperform static scheduling. 

It is generally true that simple, stream¬ 
lined instruction sets reduce hardware 


control complexity and tend to produce 
faster pipelined implementations than 
complex instruction sets. However, it 
does not logically follow that less hard¬ 
ware control complexity leads to better 
performance. When complexity is di¬ 
rected toward greater instruction func¬ 
tionality, performance often does suffer, 
but carefully chosen control complexity 
can a)so be directed toward greater per¬ 
formance. 

There is a performance/complexity 
trade-off curve, but it is not clear that the 
maximum performance point occurs at 
the minimal complexity end of the curve. 
It may very well be that some additional 
control complexity can be effectively 
used to increase performance. The risk, 
of course, in increasing control complex¬ 
ity is that performance advantages can be 
offset by slower control paths and an 
increased clock period. The ZS-1 is a 
successful attempt at achieving im¬ 
proved performance levels by using an 
architecture that naturally leads to mul¬ 
tiple instruction streams and dynamic 
instruction scheduling. Despite using dy¬ 
namic scheduling, the ZSfl’s 45-nano- 
second clock period is the fastest we 
know of for standard TTL-based ma¬ 
chines. 

The result is an architecture that can 
achieve vector levels of performance on 
highly parallel, vectorizable code. Fur¬ 
thermore, and more importantly, similar 
performance levels can be achieved with 
many less parallel, nonvectorizable 
codes. This is done by mixing advanced 
static scheduling techniques, based on 
loop unrolling (and simple forms of trace 
scheduling), with advanced dynamic 
scheduling techniques. It is important to 
note the “orthogonality” of advanced 
static scheduling techniques and dy¬ 


namic scheduling. Static scheduling can 
go a long way toward high performance, 
but this article has shown that dynamic 
scheduling can extend performance be¬ 
yond that achievable with static schedul¬ 
ing alone. 

A final observation is that compiler 
complexity and compilation times are 
often considered to be of little conse¬ 
quence when discussing hardware con¬ 
trol complexity/performance trade-offs. 
This is not absolutely true, however. 
Mature compilers take considerable time 
to construct, and in many program devel¬ 
opment environments compilation times 
using advanced static scheduling meth¬ 
ods can become excessively long. Using 
dynamic scheduling provides good per¬ 
formance on nonoptimum code. This 
means that immature compilers, or very 
fast compilers with reduced optimiza¬ 
tion, can come close to achieving the full 
potential of a computer that uses dy¬ 
namic scheduling methods. □ 
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Design Recovery for 
Maintenance and Reuse 


Ted J. Biggerstaff 

Microelectronics and Computer Technology Corporation 


S oftware maintenance and harvest¬ 
ing reusable components from soft¬ 
ware both require that an analyst 
reconstruct the software’s design. Unfor¬ 
tunately, source code does not contain 
much of the original design information, 
which must be reconstructed from only the 
barest of clues. Thus, additional informa¬ 
tion sources, both human and automated, 
are required. Further, because the scale of 
the software is often large (hundreds of 
thousands of lines of code or more), the 
analyst also needs some automated sup¬ 
port for the understanding process. 

. De sign re covery ^ create s -^gsign 
abstmctionsTrom a combination of xode, 
existing d esign docu mentation (if avail¬ 
able ), personal experience, and gene ral 
noiowiedge about problem and application 
'domains'. ( I use the"teiin 'abslraclioil'^in 
its general sense and specifically not in the 
abstract-data-type sense. Thus, the 
abstractions I discuss are generalized 
structures that contain fewer details than 
found in the source code. Any reference to 
ADTs will be explicit.) 

The recovered design abstractions must 
include conventional software engineer¬ 
ing representations such as formal specifi¬ 
cations, module breakdowns, data 


.~l 

The Desire system 
helps software 
engineers understand 
programs by analyzing 
code, relying on the 
analyst’s own 
reasoning, and 
drawing on a 
knowledge base of 
design expectations. 


abstractions, dataflows, and program de¬ 
scription language. In addition, they must 
include informal linguistic knowledge 
about problem domains, application idi¬ 
oms, and the world in general. In short, 
design recovery must reproduce all of the 
information required for a person to fully 


understand what a program does, how it 
does it, why it does it, and so forth. Thus, 
design recovery deals with a far wider 
range of information than found in conven¬ 
tional software engineering representa¬ 
tions or code. 

Design recovery occurs across a spec¬ 
trum of activities from software develop¬ 
ment to maintenance. The developer of 
new software spends a great deal of time 
trying to understand the structure of simi¬ 
lar systems and systems components. The 
software maintainer spends much of his or 
her time studying a system’s structure to 
understand the nature and effect of a re¬ 
quested change. In each case, the analyst is 
involved in design recovery. Thus, design 
recovery is a common, sometimes hidden 
part of many activities scattered through¬ 
out the software life cycle. 

A system expert provides one of the 
most effective ways to recover the design 
of a foreign system by answering ques¬ 
tions, shifting attention quickly to ger¬ 
mane areas of the program, interpreting 
code segments in human (informal) terms, 
and so forth. An automated system would 
need access to the same kind of “in-head” 
expertise. That is, it would need a knowl¬ 
edge base — a domain model — that cap- 
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Figure 1. The basic design recovery process. 


tures this expertise. The information must 
be domain oriented, must include more 
information than the analyst might find in 
the code alone, and must guide and assist 
the process of understanding the code. The 
domain model differentiates design recov¬ 
ery research frojn such superficially simi¬ 
lar efforts as reverse engineering, which 
automatically abstracts code to a specifica¬ 
tion level such that the specifications can 
be modified and revised code can be auto¬ 
matically regenerated. In fact, the domain 
model is central to the overall success of 
any attempt to automate portions of the 
design recovery process. 

Design recovery in the broad sense is so 
inherently unstructured and unpredictable 
that few tools have been available to help 
the analyst search through code to find 
patterns and structures of interest. Excep¬ 
tions include simple search tools like grep 
(a pattern searching tool for Unix) and 
some code analysis facilities in tools like 
Cscope (an interactive cross-reference 
tool, also for Unix). Further, there have 
been few tools to help the software engi¬ 
neer capture, organize, and present the 
design information once recovered, other 
than text editors, outliners, and computer- 
aided software engineering tools. 

To show how we might extend the auto¬ 
mated assistance available to the software 
engineer, this article introduces the con¬ 


cept of design recovery, proposes an archi¬ 
tecture to implement the concept, illus¬ 
trates how the architecture operates, de¬ 
scribes the progress toward implementing 
it, and compares this work with other’ 
similar work such as reverse engineering 
and program understanding. 

The design recovery 
process 

A key objective of design recovery is to 
develop structures that will help the soft¬ 
ware engineer understand a program or 
system. Understanding is critical to many 
activities — maintenance, enhancement, 
reuse, the design of a similar new system, 
and training, to name a few. This section 
describes the process of design recovery as 
it is applied to maintenance and to the 
population of reuse and recovery libraries. 
I then outline how a recovery knowledge 
base (the domain model) can assist in some 
of the steps of design recovery. 

The design recovery process consists of 
three steps: 

Step one: supporting program under¬ 
standing for maintenance. Figure 1 illus¬ 
trates the steps of the design recovery 
process that help a software engineer un¬ 
derstand a C program. Other classes of 


languages, such as object-oriented lan¬ 
guages, require a modest variation of these 
ideas. 

The analyst first looks for large-scale 
organizational structures such as the sub¬ 
system structure, module structure, and 
important data structures. Next, he or she 
recovers various useful design structures 
and expresses them in abstracted forms, 
such as informal diagrams, informal con¬ 
cepts and relations, design rationale, mod¬ 
ule structures, flow, and control. In the 
course of this, the software engineer keeps 
track of the relationship (the mapping) 
between the various abstractions and the 
segments of code that implement them. 
Now, let us look at the kinds of questions a 
software engineer asks when trying to 
understand a system. 

What are the modules? Some program¬ 
ming languages formalize the notion of a 
module and provide constructs to define it, 
so the module and subsystem structures are 
easy to determine directly from the source 
code. For those languages that do not pro¬ 
vide constructs, the software engineer 
must use a combination of human intuition 
and experience, clues from the source code 
structures, and some knowledge (expecta¬ 
tions) of the conventional organization 
patterns for applications of the type under 
consideration. 
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Figure 2. Design recovery extensions supporting reuse library population. 


Expectations derived from organiza¬ 
tional conventions are powerful and effi¬ 
cient mechanisms for helping the software 
engineer understand a system. For ex¬ 
ample, based on their knowledge of typical 
organizational patterns, experts in the 
domain of Unix-like multitasking code 
would expect to find a module that does 
process management and contains routines 
for the creation, suspension, and deletion 
of processes. Of course, such expectations 
are typically generalizations and, there¬ 
fore, are only approximations of such 
multitasking code. Thus, our expectations, 
drawn from various domains, provide 
fuzzy patterns to guide our search and 
analysis of foreign code. But, because of 
their fuzziness, these patterns can do no 
more than serve as guides. 

In addition to identifying large-scale 
structures such as modules, we also need to 
associate the structures with informal 
semantic concepts. That is, we need to 
provide semantically rich natural-lan¬ 
guage abstractions, or conceptual 
abstractions , that represent the essential 
concept underlying the module. For ex¬ 
ample, process management would be a 
good conceptual abstraction to associate 
with the example module discussed above 
because the phrase will help the software 
engineer understand the target system by 


referencing his or her existing mental 
concept and activating a variety of impor¬ 
tant and powerful expectations. 

I will formalize these conceptual 
abstractions to the point that some measure 
of intelligent computer processing can be 
implemented on them. I am not suggesting 
fully automating the design recovery proc¬ 
ess; the degree of automation is unlikely to 
ever go beyond the notion of an assistant 
that can perform wide-ranging searches 
and suggest domain-based recovery strate¬ 
gies to the software engineer. However, 
even these limited capabilities would be 
quite valuable to an analyst faced with 
hundreds of thousands of lines of foreign 
code. 

What are the key data items ? Among the 
other first questions an analyst asks are 

• What are the important data items? 

• What abstract informal concepts do 
they relate to? 

• What are their relations to the modules 
just identified? 

For example, in the multitasking window 
system example, the analyst might find a 
process table containing entries that de¬ 
scribe the processes currently running 
under the multitasker. The more experi¬ 


ence the analyst has with multitasking 
systems, the richer the set of expectations 
that he or she will have about such a sys¬ 
tem. 

What are the software engineering arti¬ 
facts? As shown in Figure 1, the under¬ 
standing process recreates the software 
engineering-oriented design artifacts and 
expresses them wherever possible in terms 
of the module and data abstractions recov¬ 
ered earlier. The specific artifacts captured 
are determined to some extent by the proc¬ 
ess model adopted by the programming 
organization. For example, some compa¬ 
nies will use a program description lan- 
gauge, dataflow, module refinement, and a 
simple data dictionary. Others will depend 
on different design artifact sets. The tech¬ 
niques under investigation at MCC are 
flexible enough to apply to a broad range of 
such artifacts. 

What are the other informal design 
abstractions? For the set of abstractions to 
be really effective, we need other informa¬ 
tion structures, many of which are not as 
well defined and formal as the software 
engineering-oriented design artifacts. For 
example, design rationale might be useful, 
perhaps stated in terms of issue-based in¬ 
formation systems (IBIS) nets. 1 Further, 
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natural-language prose is unavoidable if 
we want a really effective model of the 
design. Similarly, informal diagrams de¬ 
scribing abstract views of the target system 
are often quite useful. Thus, we must ex¬ 
pect to recover a wide variety of design 
artifacts that contain a mixture of formal 
and informal information. 

What is the relation of the design 
abstractions to the code ? After recovering 
the artifacts, we must preserve the relation¬ 
ships among them. That is, once we deter¬ 
mine that a context switch is being per¬ 
formed within some dataflow diagram, we 
would like to know exactly which chunk of 
code performs it. Code analysis of a con¬ 
crete example is often required to answer 
questions that depend on low-level details 
abstracted out of the dataflow diagram. 
Once an engineer establishes this 
abstraction-to-code link, he or she will 
have an organized, “in-head” framework 
(the abstraction) in which to put the code- 
oriented details and, perhaps more impor¬ 
tantly, a set of organized structures to help 
interpret those details. Thus, the engineer 
can understand t£e code in terms of the 
abstractions in the framework. 

Step two: supporting population of 
reuse and recovery libraries. How might 
we productively use the recovered design 
components? Populating the component 
library of a reuse system is an obvious and 
valuable use, but that requires further steps 
to generalize the components to enhance 
their reusability. Figure 2 illustrates this 
process. Generalization makes the compo¬ 
nents applicable to a wider spectrum of 
applications, but it can require that we 
factor them to decouple independent de¬ 
sign aspects. For example, an independent 
process-management component might 
apply far more widely than one that is 
tightly coupled to window management. 

The final step in this process integrates 
the new abstractions into the reuse library 
and the recovery knowledge base (the 
domain model). Thus, we expect to reuse 
this recovered information to help build 
similar new components and to recover 
similar components from other systems. 

Step three: applying the results of 
design recovery. The final step of the 
process cycle applies the newly populated 
domain model to design recovery (see 
Figure 3). The abstract design components 
stored in the domain model now become 
the starting point for discovering candidate 
concrete realizations of themselves in a 


new system’s code. Once the software 
engineer determines that the candidate is 
truly a concrete realization of the abstract 
design component, the design recovery 
system records the finding. For example, 
domain model information about the ex¬ 
pected kinds of functions in the process 
management example might provide a 
skeleton for that module and even provide 
some semantic clues about the names of 
the various routines in the module. 

Of course, the expectations in the do¬ 
main model will seldom be an exact match 
of the design structures in the source code, 
and the software engineer will likely have 
to edit the design abstraction to synchro¬ 
nize it with the code, but even a partial 
match reduces the overall work. Further, 
each significant mismatch provides new 
expectations that help the domain model 
grow and evolve. 

Distinguishing 
properties of design 
recovery 

Two key properties distinguish this de¬ 
sign recovery model from similar models: 

(1) Use of informal information. The 
model exploits multiple kinds of informa¬ 
tion. Importantly, it uses informal infor¬ 
mation, which exists outside of the sphere 
of programming languages and opens a 
new kind of leverage on the recovery prob¬ 
lem — one that exploits a human-oriented, 
associative style of retrieval and analysis. 


(2) Use of a domain model. This design 
recovery model also exploits multiple 
sources of information. In particular, it 
uses a domain model to help the software 
engineer understand and interpret foreign 
systems. The domain model is a knowl¬ 
edge base of expectations expressed as 
patterns of program structures, problem 
domain structures, language structures, 
naming conventions, and so forth, which 
provide frameworks for the interpretation 
of the code. These frameworks can be built 
on to recreate the design information that is 
missing from the code as written. Hereto¬ 
fore, such expertise has existed only in the 
minds of expert software engineers or 
application domain specialists. 

Conceptual abstractions: the use of 
informal information. Among the infor¬ 
mation developed by the design recovery 
process are instances of conceptual 
abstractions that help the user understand 
the nature of a design in human terms. That 
is, the conceptual abstraction instances 
produced by design recovery must go 
beyond what can be represented in pro¬ 
gramming languages. They represent the 
world not only in rigid formal terms, but 
also in informal and flexible terms. Such 
artifacts are not simply optional, informal 
additions to the formalisms expressed in 
the programming language, but comple¬ 
mentary representations that are necessary 
and critical to the mental structuring and 
assimilation of the final design by a soft¬ 
ware engineer. 

Note that I distinguish between the no- 
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tion of a conceptual abstraction (“a process 
management module”) and a specific in¬ 
stance of a conceptual abstraction (“the 
specific process management module in 
the Unix system”). This distinction is 
important because each has a distinct role. 
Conceptual abstractions are implemented 
in the domain model as object-oriented 
classes that take an active role in identify¬ 
ing instances of themselves in the code 
being interpreted. Thus, they represent the 
set of realizations of that object type in the 
target code, whereas an instance repre¬ 
sents a single, specific realization of that 
object in the code. The sidebar, “Concepts 
of object-oriented programming,” further 
clarifies the distinction between class and 
instance. 

If a recovered design contains this addi¬ 


tional kind of entity — the conceptual 
abstraction instance—how do we identify 
it? And, what is the character of such an 
entity? 

An instance of a conceptual abstraction 
has two important properties, one that is 
structural and one that is semantic or asso¬ 
ciative. The associative part of the 
abstraction is represented in the domain 
model by a “linguistic idiom.” The struc¬ 
tural part is represented by various kinds of 
idioms, depending on the kind of informa¬ 
tion being represented. Introducing asso¬ 
ciative connections and structural patterns 
provides a partial formalization for infor¬ 
mal conceptual abstractions. 

Structural pattern. A conceptual ab¬ 
straction’s first property is its ability to 


represent (that is, both hide and relate) 
some set of lower-level details. For ex¬ 
ample, a single concept such as “a process 
management module” can be used in many 
contexts to represent all of the massive 
detail that is a process management mod¬ 
ule, keeping the designer from becoming 
overwhelmed by the detail. This property 
is similar to the conventional software¬ 
engineering notion of expressing designs 
as top-down refinement structures. Its 
function is to describe the successively 
burgeoning levels of detail in a design. A 
conceptual abstraction’s structure has an 
additional, operational role as a pattern 
that defines the kinds of source code struc¬ 
tures that would express the abstraction. 
This pattern is used to search for and iden¬ 
tify specific source code structures that are 


Concepts of object-oriented 
programming 

The domain model in the Desire design recovery system 
is strongly related to the concepts of object-oriented pro¬ 
gramming systems (OOPS), such as Smalltalk, 1 C++, 2 and 
the Common Lisp Object System (CLOS). Central to OOPS 
is the concept of a class, which is a package of local data 
items that defines the state of an instance of the class, and 
a set of functions that manage that state. An instance of a 
class (also called an object) is a unique copy of the local 
data items; to put it another way, it is a specific concrete 
member of the class. Each data item is called an instance 
variable. The functions of the class are conventionally 
called methods. 

An example of a class would be line_segment, which 
might have instance variables x, y, and length that define 
the position of the line segment’s end point and its length. 
There might be many specific lines in a drawing, and each 
would be represented by an instance of the class, that is, a 
data record containing three values for x, y, and length. 

The methods of such a class might be named create, de¬ 
stroy, move, rotate, stretch, draw, and so forth. These 
methods would operate on the instance variables to per¬ 
form various operations on the line. 

To call such a method, we would send a message to an 
instance of the class. Sending a message is a generaliza¬ 
tion of the notion of a function call, and it requires at least 
two pieces of information to perform the invocation: a 
pointer tq an instance (from which the system can deter¬ 
mine which class to look in for the method definition) and 
the name of a method (such as move). The method name 
is called the selector. These two pieces of information 
uniquely determine the specific method to be called. Some 
object systems, such as CLOS, provide an optional, special 
case where additional items can be required, allowing a 
finer-grained determination of the specific method to be 
called. 


A key concept in OOPS is inheritance, which allows us 
to specify a new class by defining only the differences be¬ 
tween it and another class, called its superclass. For ex¬ 
ample, we could specify a class fat_line_segment by de¬ 
claring it as a subclass of line_segment and describing the 
differences. We would say line_segment is the superclass 
of fat_line_segment. Suppose this new class has an addi¬ 
tional instance variable named width, which defines the 
width of the line to be drawn. Its instance records will con¬ 
tain variables x, y, and length, inherited from line-segment, 
and the variable width, from fat_line_segment’s definition. 
Similarly, we would write a new version of the draw and 
create methods to accommodate the operational differ¬ 
ences between simple line segments and those with width. 
These new methods would be called whenever the draw or 
create messages were sent to one of fat_line_segment's 
instances. When other messages, such as stretch, are 
sent, the inherited methods from line_segment would be 
called. 

Frames, a slight variation of the concept of classes, 
come from the field of artificial intelligence. They usually 
have more built-in conventions for the instance variables 
(commonly called slots in frame systems) than simple 
OOPS classes do. They therefore have more associated 
runtime support. Frames systems often include conven¬ 
tions and runtime support for expressing relationships be¬ 
tween instance records. For example, semantic net appli¬ 
cations often provide frame conventions and built-in facili¬ 
ties that search the frame network for sets of instances 
that resemble but do not exactly match each other. Such 
frame conventions and support are often built on top of a 
conventional OOPS system. 
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#include <stdio.h> 

#include “hOOO 1 .h” 

#include “h0002.h” 

#include “h0003.h” 
fOOOl(aOOOl) 

unsigned int aOOOl; 

{ 

unsigned int iOOOl; 

f0002(g0005 ,dOOO 1 ,d0002); 

f0002(a0001 ,d0003,d0002); 

f0003(g0001 [aOOO 1 ] .sO0O 1 ,gOOO 1 [aOOO 1 ] .s0002); 

g0006 = aOOOl; 

iOOO 1 = gOOO 1 [aOOO 1 ]. s0003; 

if(!f0004(iOOO 1) && ( g 0002->g0003)[i0001].s0004 == d0004) 
f0005(i0001); 

1 

Figure 4. Function with no informal semantic clues. 


~j 


#include <stdio.h> 
#include “proc.h” 

#include “window.h” 
#include “globdefs.h” 
change_window(nw) 

unsigned int n' 


unsigned int pn; 

border_attribute(cwin,NORM_ATTR,INV_ATTR); 
border_attribute(nw,NORMHLIT_ATTR,INV_ATTR); 
move_cursor(wintbl[nw].crow,wintbl[nw].ccol); 
cwin = nw; 

pn = wintbl[nw].pnumb; 

if(!outrange(pn) && (g->proctbl)[pn].procstate == SUSPENDED) 
resume(pn); 

) 


Figure 5. Function with some informal semantic clues. 


plausible instances of the conceptual ab¬ 
straction. 

Associative connections. A conceptual 
abstraction ’ s second property is its rich set 
of informal, natural-language associations 
that establish its contextual framework for 
human understanding. That is, the concept 
of a process management module has 
semantic connections to other informal, 
semantic concepts such as context switch¬ 
ing, state saving, arid multitasking. Each of 
these concepts allows association of the 
concept of a process management module 
with a large body of knowledge that can 
help an engineer interpret the design of 
some specific process management mod¬ 
ule or plan the design of a new one. 

These two properties provide clues to 
the role of conceptual abstractions in deal¬ 
ing with large complex designs. The struc¬ 
tural property provides a way to handle lots 
of detail without being overwhelmed, as 
well as a way of describing the application 
patterns one expects to find in programs. In 
contrast, the associative linguistic prop¬ 
erty offers a way to deal with partially 
specified (fuzzy) design objects within the 
universe of informal, natural language- 
based semantics. These properties relate to 
two parallel and complementary models 
— the software-engineering representa¬ 
tion model and the natural-language se¬ 
mantic model. 

The importance of informal informa¬ 
tion. An example will illustrate the impor¬ 
tance of the informal aspect of conceptual 
abstractions. Consider the C function in 
Figure 4. This is a real function taken from 
a multitasking window system 2 with the 
comments removed and meaningful iden¬ 
tifiers mapped to semantically empty 
symbols. What could an analyst tell about 
the computational intent of this function? 
Precious little. About all he or she could do 
is paraphrase the relations expressed in the 
programming language. For example, the 
analyst could describe that the function 
fOOOl calls f0002 with arguments that are 
global arrays (such as gOOO 1) of structures 
containing some fields (such as sOOOl and 
s0002). Even if the definitions of all of the 
functions (f0002, f0003, etc.) were avail¬ 
able and similarly transformed, the com¬ 
putational intent would remain unclear. 
What is worse is that, without the informal 
information, the computational intent of 
these functions might not be unique. There 
could be a number of valid interpretations. 

The example severs the connection be¬ 
tween the artifact and the semantics of the 


problem domain, eliminating associations 
between the program and our informal 
knowledge of the world. Interpretation and 
understanding of the program has become 
impossible in any deep sense. Thus, we can 
see that connotation plays an important 
role in the process by which people deal 
with, interpret, and understand programs. 

It is exactly this kind of semantically 
impoverished representation that we usu¬ 
ally give to automated tools. If people have 
difficulty dealing with this kind of repre¬ 


sentation, why should we expect a com¬ 
puter to be more successful? 

So what sort of informal information is 
required to understand the program in a 
nonsuperficial way? Let us consider a 
slightly enhanced versiori of this program. 
Figure 5 maps the symbolic names back to 
those used in the original code. Here, the 
names of the functions are more meaning¬ 
ful and, if the reader understands a bit 
about multitasking and window systems, 
he or she can probably make some good 
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#include <stdio.h> 

#include “proc.h” 

#include “window.h” 

#include “globdefs.h” 

change_window(nw) /^Change current window to window nw*/ 

unsigned int nw; /*Number of target window*/ 

{ 

unsigned int pn; 

/♦Restore border of current window to un-highlighted*/ 
border_attribute(cwin,NORM_ATTR,INV_ATTR); 

/♦Highlight border of new current window*/ 
border_attribute(nw,NORMHLIT_ATTR,INV_ATTR); 

/♦Move the physical cursor to the new window where the cursor was 
left, and make nw the current window*/ 
move_cursor(wintbl[nw].crow,wintbl[nw].ccol); 
cwin = nw; 

/♦Resume the process associated with the new window if it is 

suspended.*/ 

pn = wintbl[nw].pnumb; 

if(!outrange(pn) && (g->proctbl)[pn].procstate == SUSPENDED) 
resume(pn); 

} 


Figure 6. Function with many informal semantic clues. 


guesses about the operation. The name of 
the function suggests that it changes which 
window is currently active, with the new 
window probably indicated by the argu¬ 
ment nw. Further, we can guess that the 
function border_attribute alters the visual 
appearance of the windows’ borders, the 
function move_cursor moves the screen 
cursor to some position in the new win¬ 
dow, and the function resume allows some 
suspended process to run again (probably 
the process associated with the new win¬ 
dow). The variables similarly come alive 
with meaning: wintbl is probably the win¬ 
dow table and probably has fields ccol and 
crow that keep track of the cursor (inferred 
from their use in the call to move_cursor). 

By restoring the comments from the 
original code (see Figure 6), we can cor¬ 
roborate several of our guesses and en¬ 
hance our understanding of some of the 
functions and variables. 

This exercise should make it clear that 
the informal linguistic information that the 
software engineer deals with is not simply 
supplemental information that can be ig¬ 
nored because automated tools do not use 
it. Rather, this information is fundamental. 


It provides the ability to determine the 
computational intent of code in a way that 
is impossible with just the source code 
denuded of its informal semantics. 

If we are to use this informal informa¬ 
tion in design recovery tools, we must 
propose a form for it, suggest how that 
form relates to the formal information 
captured in program source code or in 
formal specifications, and propose a set of 
operations on these structures that imple¬ 
ments the design recovery process. To 
accomplish these goals, we must first ana¬ 
lyze the proposed design recovery system 
in a bit more detail. 

A model-based design 
recovery system 

What would a design recovery system 
look like? Figure 7 is a system-level de¬ 
scription of a model-based design recov¬ 
ery system (called Desire) showing some 
of the sources of information used to re¬ 
cover designs. They include the code of 
existing systems because such code con¬ 


tains a large amount of important informa¬ 
tion, but there must be other sources as 
well. Much design information cannot be 
formally captured in the program source 
code because programming languages do 
not contain the constructs necessary to 
express information such as the informal 
conceptual abstractions behind the code. 
For example, the informal conceptual ab¬ 
stractions behind the change_window 
function discussed earlier include win¬ 
dows, processes, cursors, and the opera¬ 
tions on these entities. And these concep¬ 
tual abstractions are woven into a rich set 
of knowledge about the domain that pro¬ 
vides clues to understanding the formal 
source code structures. 

Design recovery results in a hypertext 
web 4 of information that weaves together 
informal ideas (e.g., the concept of a proc¬ 
ess), software engineering artifacts (e.g., a 
dataflow diagram of a process switch), and 
details of specific examples of these enti¬ 
ties as embodied in code (e.g., one specific 
subroutine for process switching). This 
web is projected into externalized reports 
to help the software engineer understand a 
specific target system and into internalized 
data structures for use by the Rose reuse 
system. 3 Since the web is built out of hy¬ 
pertext frames, the design recovered by the 
Desire system is simply a set of data struc¬ 
tures that represent the conceptual 
abstractions and express the semiformal 
relationships among them (see sidebar, 
“Concepts of object-oriented program¬ 
ming”). 

To understand how this model-based 
design recovery system works, the nature 
of the data items in the model, and how 
those data items are used, consider the 
following typical design recovery session 
using the multitasking window system as 
the application domain. Using the process 
model of design recovery as a guide, I will 
first define a set of data objects (called 
idioms) that implement the structural pat¬ 
terns and associative connections of con¬ 
ceptual abstractions. The example idioms 
codify the domain model’s expectations of 
the entities and structures in a typical 
multitasking window system running on a 
personal computer. I will then informally 
describe how these domain objects behave 
during the semiautomated recovery of the 
design of a specific multitasking window 
system. This scenario is analogous to a 
nonautomated design recovery performed 
by an unaided software engineer. 

An example. We start to discover the 
structure of this multitasking window sys- 
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Figure 7. The Desire model-based design recovery system. 


tern by looking for key structures, based on 
our knowledge or expectations of the prob¬ 
lem and application domains. A knowl¬ 
edgeable engineer would expect to find a 
process table, a window table, a window 
management module, and a process man¬ 
agement module, among other structures. 
(I offer a detailed example of such a system 
elsewhere. 2 ) 

In Desire’s domain model, such expec¬ 
tations are represented by object classes 
expressed in the Common Lisp Object 
System (CLOS). In contrast to object 
classes that implement a window manage¬ 
ment module or a process management 
module, these domain model classes 
operate on the implementations of window 
management modules or process manage¬ 
ment modules. Specifically, domain model 
objects search for instances of the key 
structures within the code (perhaps with 
human help) and bind their instance vari¬ 
ables to these key structures, subject to the 
analyst’s approval. An instance of such a 
domain object represents an occurrence of 
a concept such as a window management 
module or a process management module 
within a specific segment of source code. 


The instance variables of that instance 
point to the segments of code that imple¬ 
ment the domain object. 

Thus, the first step of recovery is to 
create a set of instances of the idiomatic 
structures expected. The engineer exam¬ 
ines the domain model, finds an object 
class describing a multitasking window 
manager, and creates an instance of that 
object. As a side-effect, other instances 
that define the detailed substructure of a 
multitasking window manager are created 
as a substructure of this first instance. This 
structure of instance records represents an 
architectural overview of a multitasking 
window manager that might look 
abstractly like the structure in Figure 8, 
where the relation on the arcs is the sub¬ 
parts relation. Over the course of the de¬ 
sign recovery process, the whole set of 
design details will evolve as a rich sub¬ 
structure beneath this first set of instances. 
Now let’s follow the evolution of that 
substructure in more detail. 

Each of the instances just created can 
bind to the source code in one of two ways: 

(1) It can bind directly to some segment 




Multitasking / 

Process 
/ table 

Window 
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Figure 8. Initial pattern instance rec¬ 
ords expressing an architectural over- 


of code (associatively). 

(2) It can bind indirectly through a 
subinstance (that is, through a close 
match of the substructures to the 
program code). 
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Figure 9. Abstract design idioms within a domain model. 


For example, the process table class in 
Figure 9 contains idioms for both kinds of 
binding. 

Direct binding is implemented via a 
linguistic idiom, which represents the 
expected linguistic form of a conceptual 
abstraction such as process table. This id¬ 
iom might be implemented as a set of 


regular expression patterns that match the 
various natural-language forms in source 
code identifiers or comments. For ex¬ 
ample, the pattern [pr.clprc] [.?!.. I...I ] 

[t.bltbl] defines the linguistic expectations 
for process table. Of course, we will occa¬ 
sionally encounter an expression of the 
conceptual abstraction that the existing 


patterns do not find. The addition of such 
cases helps the domain model grow and 
evolve. 

How would the recovery system use 
these patterns? We would seldom want to 
recklessly search a large system to find all 
of the associations. Not only would such a 
search take a large amount of computation 
time, it also would probably introduce a 
large number of false positive hits, thereby 
taking a lot of analyst time to sort out the 
results. Instead, we would prefer to be 
more selective and use our knowledge of 
programs, systems, and domains to focus 
the search. For example, in the C language 
we would expect to find the definition of 
the process table in some header file and so 
would narrow our initial search to those 
files. This search might find the chunk of 
code in Figure 10. 

Given this structure as a starting point, 
the system uses the data object idiom that 
defines the substructure of a process table 
and recursively applies the search against 
the code structure in Figure 10, using the 
patterns from the classes of each of the 
subparts of a process table. (Actually, I 
have simplified this example by ignoring 
the intervening conceptual structure—the 
process table entry.) Figure 11 illustrates 
this recursive step, which binds the fields 
within the source code definition of the 


—- 1 

process proctbl[MAXPROCS]; 

/* Process tbl array */ 

typedef struct procentry 

j 

/* Process table entry */ 

unsigned int savesp; 
unsigned int savess; 
unsigned int pspseg; 
unsigned int windno; 
unsigned int procstate; 
char procname[M AXPN AME+1 ]; 
int pnum; 

/* Saved sp register */ 

/* Saved ss register */ 

/* PSP seg addr this proc */ 

/* Window number this proc */ 

/* Process state */ 

/* Process name */ 

/* Process number for this entry */ 

} process; 



Figure 10. Structure found via search of source code. 
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Process 

Location of 

Location 

number 

name 

state 

saved envir. 

of process 


process proctbl[MAXPROCS]; /* Process tbl array 7 


typedef struct procentry 
{ 

unsigned int savesp; 
unsigned int savess; 
unsigned int pspseg; 
unsigned int windno; 

► unsigned int procstate; 


r Process table entry 7 

/* Saved sp register 7 
/* Saved ss register 7 
/* PSP seg addr this proc 7 
/* Window number this proc 7 
/* Process state 7 


char procname[MAXPNAME+1 ]; /* Process name 7 

int pnum; /* Process number for this entry 7 


Figure 11. Bindings to substructures in source code. 


process table to the instance records that 
define the expectations of those fields. 

The recovered design in Figure 8 has 
now evolved into that in Figure 12, where 
the dashed lines show the bindings be¬ 
tween abstractions and code. Note that the 
matching of idiom pattern to code is inex¬ 
act, with some instances of the idiom un¬ 
bound and some elements of the struct 
unexplained. We can typically expect an 
automated aide to produce only partial 
matches, leaving part of the interpreta- 
tional work to the software engineer. Thus, 
the analyst will likely have to specialize 
(edit) the idiom further to reflect the spe¬ 
cific case. However, the partial match 
provides enormous benefit by focusing the 
analysis and establishing a broad frame¬ 
work in which to perform the remaining 
interpretation. The partial match provides 
a starting point by identifying some of the 
substructures of the idiomatic form, mak¬ 
ing completion of the interpretation far 
simpler than starting from scratch. 

So, for data structures in the source 
code, at least two kinds of information 
express the key idiomatic features of the 
source code. The linguistic idiom ex¬ 
presses the natural-language tokens (gen¬ 
eralized into search patterns) that we ex¬ 
pect to be associated with key data struc¬ 
tures. The data object idioms express the 


substructure relationship within complex 
data structures. We can exploit structural 
idioms to discover design structures for 
the first time (in a top-down manner) as 
well as to verify associations with large- 
scale structures discovered earlier (as a 
bottom-up verification). 

This pattern of linguistic and structural 


design idioms repeats itself when we ex¬ 
amine what kinds of structures the domain 
model must contain to describe the expec¬ 
tations about module structure, dataflow 
plans, and so forth. For example, in the 
context of a Unix-like multitasking sys¬ 
tem, we would expect to find a process 
management module with routines for 




Process 

state 

Process 

name 

Process 

number 


Figure 12. Pattern of instance records with some bindings to code. 
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creating a process, resuming a process, 
suspending a process, and so forth. Much 
as in the data structure idiom, these expec¬ 
tations form an initial framework that 
might fuzzily match some functions in the 
code. From here, the software engineer can 
read and analyze the code and then special¬ 
ize the domain model patterns to fit the 
current case. Other artifacts such as dat¬ 
aflow schemas operate in a similar fashion. 

Using idioms to guide the search and 
then act as the skeletal organizing structure 
for the recovered design offers two impor¬ 
tant benefits: 

(1) The domain model idioms encode 
expectations as preformed queries, elimi¬ 
nating the need to constantly reenter these 


query forms during program analysis. 

(2) The system records the resulting 
design in terms of both informal linguistic 
abstractions and semiformal software 
engineering structures. 


Desire prototype and 
current work 


MCC has developed a prototype of a 
design recovery system called Desire 
Version 1.0. The system is intended to 
explore only that aspect of design recovery 
that does not depend on the domain model. 
Thus, it is an interim system designed to 
lay the foundation for the full Desire sys¬ 


tem by providing a baseline of facilities to 
process the information explicitly found in 
source code. 

Figure 13 shows Desire Version 1.0 in 
operation. The system consists of three 
major parts: a parser, a set of post¬ 
processing functions, and the PlaneText 
hypertext system 4 as the presentation en¬ 
gine. The parser processes a set of C files 
for a given system and produces a set of 
parse trees. We anticipate the need to use 
much of the informal linguistic informa¬ 
tion encoded in variable names, comments, 
and the like, so the parser must take special 
care to preserve this information. 

A set of postprocessors takes the parse 
trees as input and produces a dictionary 
containing information on functions, the 


Related work 


Related research 
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Commercial reverse engineering tools 

A number of reverse engineering tools (closely related to 
reengineering tools) have appeared on the market recently. 
These tools solve part of the problem of recovering the de¬ 
sign of an existing system. Examples are Cscope, cxref, 
Bachman/Data Analyst, and Meta’s Design/2.0. While 
these tools find, present, and analyze information in the 
source code (or in the data dictionary in the case of the 
Bachman/Data Analyst), they do not reconstruct, capture, 
and express design abstractions that are not explicitly rep¬ 
resented in the source code-related representations. Such 
design abstractions are a large part of what humans use to 
understand, modify, adapt, and otherwise deal with sys¬ 
tems and programs. The need for and absence of such ca¬ 
pabilities should indicate the direction in which these tools 
will likely evolve, and should be a mandate to push the 
technology in that direction. 

We can loosely classify commercial reverse engineering 
tools (in the broadest sense of the term “reverse engineer¬ 
ing") into the following categories: 


• test coverage analyzers; 

• debuggers and execution monitors; 

• source-to-source translators; 

• cross reference facilities; 

• code reformatters, pretty printers, and restructurers; 

• structure and metric analyzers; 

• file comparators; and 

• CASE-oriented reverse engineering (and reengineer¬ 
ing) tools. 


Since these tools are commercial, information about 
them is limited. Nevertheless, Horton 1 and Aranow 2 provide 
a short overview plus information on specific products and 
vendors. In addition, Sneed and Jandrasics 3 describe a 
prototypical CASE-oriented reverse engineering system. 


In contrast to commercial reverse engineering tools, the 
tools in the research community come closer to our notion 
of design recovery. Both sets of tools focus most often on 
program understanding, but there is a subtle difference in 
the research goals. Most tools in the area of program under¬ 
standing have focused on very small-scale problems to 
achieve precise and complete formal specifications of the 
source code. Further, they typically have not focused as 
much on informal information. In contrast, our approach 
sacrifices formal completeness and precision for scale. In 
the long run, these two approaches will likely be comple¬ 
mentary rather than mutually exclusive, with each providing 
aspects missing in the other. 

Several researchers have been working on the problem of 
understanding what a program is intended to do. 4 7 Some 
use information drawn largely from the programming lan¬ 
guage domain, such as Wills’ recognizer. 7 Others incorpo¬ 
rate more knowledge from the problem domain. In most 
cases, the scale of the target programs is quite small — 
tens or hundreds of lines of code. The most recent 
Programmer’s Apprentice work deals with larger compo¬ 
nents but does not yet deal with large, industrial sized com¬ 
ponents. 5 

Most of this work depends on analysis of the low-level, 
formal details and, therefore, emphasizes a full and exact 
match of the structure for recognition. The computational 
load required by such an approach suggests that scaling up 
to industrial sizes will be quite difficult. People appear to be 
successful at program recognition because they can attend 
to a few key features and make tentative, plausible matches 
based on similarity rather than exactness. Further, most of 
the time, many of those few key features are informal. Of 
course, humans supplement such recognition with many 
other approaches for verification and detailed understand¬ 
ing, but the initial narrowing of attention based on informal, 
partial clues seems to be critical to handling scale without 
being overwhelmed by detail. 

It seems likely that the understanding and recovery ap¬ 
proaches can be productively merged. That is, an initial 
search strategy based on informal, partial clues, followed by 
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files that contain them, the global data 
items defined, where they are defined, and 
where they are used. Informal information, 
such as that in the comments, is associated 
with the target program’s function defini¬ 
tions and data item definitions. In addition, 
the postprocessors compute and store the 
various relationships between these items 
(such as calls, uses, and depends) in the 
dictionary. 

Once this information is computed, 
another postprocessor computes a Plane- 
Text web and invokes the PlaneText 
browser to exhibit the web. PlaneText 
computes various views that exhibit some 
relationships (such as calls) and suppresses 
others. Thus, if the user wants to see a call 
lattice or the relationship between data 


items and files, the system can compute 
each of these as a separate browser view. 

The screen dump in Figure 13 suggests 
some of the prototype’s functionality. The 
prototype provides a set of predefined 
Prolog queries for computing a variety of 
questions about the data in the dictionary. 
These queries include low-level questions 
such as “What is the set of functions that 
call function j c?” as well as higher-level 
questions such as “Does any function de¬ 
fined in file A call any function defined in 
file B?" or “Compute the set of functions 
that appear to be utility functions.” This set 
of queries is evolving to include a number 
of complex program analysis functions. 
Since the user can build on these queries, 
the question set can be tailored to any 


specific application domain. 

In Figure 13, the user has used one of the 
predefined Prolog queries to ask for all 
functions that refer to a piece of data named 
call_to_times. The browser responds by 
highlighting all of the functions found by 
the query. The user inspects the visual 
design browser and identifies the name of 
the file (pow2.c) that contains the defini¬ 
tion of one of these functions (power). The 
user then opens a window on that file 
(lower left-hand corner) and uses Plane- 
Text’s regular expression-based search to 
find the location of the variable 
calls_to_times. Of course, as we determine 
which sequences in the prototype are most 
useful, we will replace them with a single 
user command. 


the more detailed kind of analysis used in the Programmer's 
Apprentice, would provide a powerful and scaleable ap¬ 
proach to automating more of the program comprehension 
process. This appears to be the most successful long-term 
direction for this kind of research. 

Other work is more loosely related but nevertheless 
shares some ideas with our work. Perhaps the overriding 
theme of this work is the integration of CASE, hypertext (or 
hypermedia), and knowledge-based technologies. In fact, 
some of our own work that contributed to our current de- 
sign-recovery notions (my large-scale reuse 8 and Lubars’ 
Rose 9 system) falls in this class, although the hypertext as¬ 
pect is largely absent in Rose. The work of Ambras and 
O’Day 10 and Bigelow 11 shares this theme to a greater or 
lesser extent, with Bigelow emphasizing hypertext and Am¬ 
bras and O’Day emphasizing knowledge-based representa¬ 
tions. Most of the work in this category is, in principle, able 
to handle large-scale information bases. 

The work by Arango et al. 12 resembles the research re¬ 
ported in the current article. These researchers have solved 
the problem of scaling up but are not creating the kind of 
high-level, informal conceptual abstractions that Desire fo¬ 
cuses on. Of course, creating such abstractions was not 
particularly important to Arango et al. because they wanted 
to port their target program (Draco, 13 in this case) com¬ 
pletely automatically from one computing environment to 
another. From this point of view, their system is more simi¬ 
lar to source-to-source translation and restructuring systems 
than reverse engineering systems of the variety I have dis¬ 
cussed. 

Abstractly, Arango et al. are also trying to recover de¬ 
signs, but some differences exist between their focus and 
ours. Their design recovery model focuses more on the 
structure of the transformations and the operations on trans¬ 
formations than it does on the structure of and operations 
on the design entities themselves. Our focus is the reverse 
of this. Further, and perhaps more importantly, their model 
makes no use of informal information because it is based on 
a commitment to complete automation. On the other hand, 
because our model strongly involves people in the design 
recovery process, we must make heavy use of informal in¬ 
formation to help human understanding. 
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Desire Version 1.0 also analyzes the 
source code and creates a graphical dia¬ 
gram describing its interpretation of the 
program’s module structure. Based on the 
user’s request, this analysis can variously 
depend on the program ’ s cohesion, its data 
coupling, and so forth. 

As a separate research task, we have 
used PlaneText 4 to sketch out a domain 
model drawn from the area of multitasking 
window systems. 2 This research task uses 
PlaneText as a simple design aid, and we 
have not yet integrated the domain model 
with the Desire Version 1.0 prototype. To 
do so, we are converting this hypertext 
design Of the domain model into a set of 
CLOS classes that are the active or im¬ 
plementation form of the domain model. 
This model bears a strong relationship to 
the semantic models created with frame 
languages like KL-One. The primary dif¬ 
ference is that the CLOS classes possess 


more specialized, local behavior. The 
classes capture 

• the isa or superclass/subclass lattice of 
the entities in the domain (e.g., a proc¬ 
ess-table is a subclass of table); 

• the informal patterns for expressing 
the entities in the domain (e.g., a proc¬ 
ess might have a variety of abbrevia¬ 
tions and synonyms); 

• the slots that are to contain the ex¬ 
pected substructure of a concept in¬ 
stance (e.g., a queue will have a queue- 
entry slot); 

• restrictions on the slots that constrain 
what values the slot can have (e.g., a 
restriction on the class of the value in 
the slot); and 

• methods that provide the entity’s be¬ 
havior (e.g., displaying the concept, 
searching for possible instances, and 
binding slots to instances). 


fair amount of work is now aimed 
at determining what the interface 
should look like and how it 
should behave. Specifically, we are work¬ 
ing on methods to visually relate the recov¬ 
ered abstract concepts to the portions of the 
program to which they refer. 

More recently, we have begun a series 
of experiments to refine our notions of 
search strategies for informal information 
and to allow fuzzy matches of expecta¬ 
tions. We believe that, in addition to the 
simple search mechanisms described ear¬ 
lier, we will be able to apply ideas from 
connectionist research 5 to perform some 
of the fuzzy matches. These searches take 
advantage of the domain model’s structure 
to allow associative searches that return 
items based on their indirect associations 
with the features sought. This part of 
the research is in an early prototyping 
stage. □ 
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Content-Addressable and 
Associative Memory: 

Alternatives to the Ubiquitous RAM 


Lawrence Chisvin, Digital Equipment Corporation 
R. James Duckworth, Worcester Polytechnic Institute 


R esearchers have understood the 
basic principles of storing and re¬ 
trieving data by content rather than 
by address for about 30 years. Despite this 
relatively long incubation period, informa¬ 
tion has spread slowly from the academic 
arena, and the technology has not been 
available to produce a successful commer¬ 
cial product. As a result, many designers 
have not developed the skills to work with 
associative and content-addressable 
memories. However, VLSI technology has 
improved the feasibility of associative 
systems and overcome many implementa¬ 
tion obstacles. 

The size and versatility of actual con¬ 
tent-addressable and associative systems 
has increased rapidly over the past few 
years, enabling support of new kinds of 
parallel and artificial-intelligence archi¬ 
tectures. Kadota et al.,' for example, de¬ 
scribe a content-addressable and reentrant 
memory, an 8-kilobit device designed as a 
high-speed matching unit in dataflow 
computers. Also, the SCAPE (single-chip 
array processing element) project in Eng¬ 
land is designing an associative parallel 
processor optimized to support image- 
processing algorithms 2 ; Ogura et al. 3 de¬ 
scribe a 20-kilobit CMOS associative 
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Systems that store 
and retrieve data 
based on its content 
rather than its 
address are finally 
commercially feasible, 
thanks to new 
technology that 
has pushed aside 
previous obstacles. 


memory IC design for Al machines; and a 
recently developed machine called Asca 
executes Prolog at high speed using con¬ 
tent-addressable memories. 4 

Our goal in this article is to explain 
content-addressable and associative proc¬ 
essing systems to people unfamiliar with 
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them and show that such systems are now 
commercially feasible. We first contrast 
content-based archiving and retrieving 
with address-based storage methods. We 
then explain the principles, advantages, 
and obstacles of content-addressable stor¬ 
age, describe associative processing meth¬ 
ods and architectures, and finally, discuss 
software for associative systems. 

Address-based storage 
and retrieval 

Traditional computers rely on a memory 
architecture that stores and retrieves data 
by addressing specific memory locations, 
as shown in Figure 1. Every accessed data 
word must travel individually between the 
processing unit and the memory reservoir 
through a communications medium, often 
a shared bus. The elegance and simplicity 
of this approach has ensured its success, 
evidenced by the ubiquitous nature of the 
computer today. However, there are some 
inherent drawbacks to a word-at-a-time, 
location-addressed memory. 

One major problem of address-based 
memory is that the memory access path 
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Figure 1. Location-addressable 
memory. 


becomes the limiting factor for system 
performance. This has become known as 
the “von Neumann bottleneck.” Much of 
the traffic on the communications medium 
is involved with sending information back 
and forth merely to calculate the effective 
address of the necessary data word. 

A second important drawback to the 
location-addressed approach is the serial 
nature of the processing, where each piece 
of information must be handled sequen¬ 
tially. This approach is particularly slow in 
search-and-compare problems, for ex¬ 
ample, where many items must be in¬ 
spected to determine the outcome. A linear 
search operation for an exact match on a 
conventional computer finds the match, on 
average, halfway down the search list. The 
search time increases at the same rate as the 
list size. The performance penalty in¬ 
creases if a more complex comparison is 
necessary while searching, such as corre¬ 
lating or sorting the data. 

Techniques such as hash coding and 
hardware execution pipelines attempt to 
alleviate the problems by reducing the 
search time and overlapping the functions. 
However, improvement using conven¬ 
tional methods is limited. 

Addressing by location is particularly 
inefficient when 

• data is associated with several sets of 
reference properties, 

• data elements are sparse relative to the 
values of the reference properties, or 

• data becomes dynamically disordered 
in memory during processing. 5 


The serious disadvantages inherent in 
location-addressed memories become 
more obvious when multiple processing 
units are introduced into the computing 
system. Modern parallel-processing archi¬ 
tectures, such as dataflow machines, ex¬ 
ploit application parallelism to increase 
their execution performance. Systems that 
rely on dataflow properties do not execute 
efficiently on a traditional memory, where 
each data word can only be accessed seri¬ 
ally by its location in a large sequential 
array. 

Content-addressable 
and associative 
memories 

The basic problems just detailed have 
led researchers to investigate content- 
addressable memories (CAMs), where in¬ 
formation is stored, retrieved, or modified 
based on the data itself, not its arbitrary 
storage location. In some ways, we can 
view such a memory as a representation of 
the information it contains, rather than as a 
consecutive sequence of locations con¬ 
taining unrelated data. 6 

A content-addressable memory has tra¬ 
ditionally been a system of fixed tag and 
data words that can be matched exactly 
according to the contents of the word, so 
multiple responses are possible for each 
search key. 

The term “associative memory” de¬ 
scribes a more general storage and retrieval 
system that can access or modify cells 
based on their contents but does not need 
an exact match with a data key. 7 Instead, it 
can use magnitude relationships such as 
less than, between limits, next higher/ 
lower, similarity, proximity, not equal, or 
minimum/maximum value. It can use a 
retrieval method based on the contents of 
neighboring locations for search and com¬ 
pare operations, especially those associ¬ 
ated with image and speech recognition. 

A special-purpose associative memory 
called an age-addressable memory uses the 
date and time when the data was written as 
a retrieval key. 8 This type of access, cer¬ 
tainly not the only special use of a particu¬ 
lar memory-content relationship, is well 
suited to queuing systems and arbitration 
logic. 

An associative processor exhibits so¬ 
phisticated data transformation or includes 
arithmetic control over the contents of a 
number of cells. Retrieval is based on a 
predefined sorting algorithm that orders 


the data as it is read from memory. Sorting 
algorithms include alphabetical, numeri¬ 
cal, and chronological, as well as special- 
purpose keys such as city of residence or 
political affiliation. In many cases, a com¬ 
bination of ordering keys is used, such as 
alphabetical within a predefined numeri¬ 
cal order. An associative processor can 
count matches for a particular key and tag 
or bufferthe responses for later inspection. 
The term “associative computer” describes 
a computer system that uses an associative 
memory or associative processor as an 
essential component for storage or proc¬ 
essing. 

The concepts of storage and retrieval 
in a content-addressable memory are 
straightforward. The basic functions are: 

• broadcast and comparison of a search 
argument with every stored location 
simultaneously, 

• identification of the matching words, 
and 

• access to the matching words. 

Figure 2 is a simple block diagram of a 
content-addressable memory. A particular 
record can be found by matching it with a 
known pattern. This process inyolves a key 
word, a mask word, and matching logic. 
The key word inputs the pattern for com¬ 
parison, while the mask word enables only 
those parts of the key word that are appro¬ 
priate in the context of the request. The key 
and mask word combination is provided to 
the tag memory and matching logic, where 
the actual data comparison takes place. 
After a match has been found, the appro¬ 
priate data words can be output to the 
requesting program or modified, depend¬ 
ing on the capabilities of the system archi¬ 
tecture and the requirements of the appli¬ 
cation. 

Figure 3 shows a common CAM data- 
word arrangement, where each data word 
is partitioned into fixed segments. In this 
scheme, three fields contain specific infor¬ 
mation. The tag bits signify the type of 
location and show whether the location is 
empty or used. If the location is used, this 
field identifies the type of information 
stored, such as temporary data or program 
code. 

The balance of the word is split into 
label and data fields. The label field 
matches incoming key word requests, and 
the aata field holds the information to be 
returned or modified. If more flexibility is 
desired, or if the label information is 
embedded in the data, these two concep¬ 
tual segments are treated as one entity. In 
this implementation, the entire data field is 
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compared with the properly masked search 
key. 

Since a search might identify more than 
one matching stored record (in fact, this is 
likely in a complex system), some method 
of sorting or outputting multiple matches 
must be provided. The two main problems 
with multiple responses are identifying the 
number of responders and selecting each 
member from the set of responses. 

Assume that a CAM contains the entries 
shown in Figure 4. This figure shows sepa¬ 
rate label and data fields and, for simplic¬ 
ity, contains no tag field. When the key 
word 1010 is applied to the CAM, three 
labels respond after the matching opera¬ 
tion. These responders have correspond¬ 
ing data items containing 386CH, 
ABCDH, and 9732H. Each of the multiple 
matches might be selected at random or in 
some predefined priority order. Assuming 
some priority, the matching words could 
be presented as they are found in an or¬ 
dered array, or they could be sorted by an 
algorithmic selection process. In Figure 4, 
they might be sorted alphabetically or 
numerically. 

After the matching operation identifies 
the associated data, it will often need to 
write new information into the CAM. This 
necessitates decisions unique to associa¬ 
tive storage. The first difficulty is deciding 
where in the memory to write the informa¬ 
tion. Since the data words are not address¬ 
able by location, some other method of 
identifying currently available memory 
areas must be used. This method must take 
into account the likelihood that certain 
data words are related to one another and 
should be stored for efficient retrieval. 

Free areas can be identified by their 
content, by a separate tag bit, or by a 
pattern in a special field. The act of writing 
a data word must be guided by this infor¬ 
mation, and an algorithm chooses the exact 
place to store a new word. The word can be 
placed at random within the free area, or a 
more predictable choice can be made. For 
example, the new data word can be stored 
in the first free memory area found (if this 
has any meaning in the particular architec¬ 
ture), or it can be placed close to other 
related data. The choice of algorithm de¬ 
pends on the intended application. Chang¬ 
ing only the partial contents of a data word 
is a desirable function, and writing to an 
arbitrary number of cells within different 
words is a potentially powerful operation. 7 

Once the location has been determined, 
the memory system must also decide 
exactly how to write the word. Since a 
content-addressable architecture relies on 
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Figure 2. Content-addressable memory block diagram. 
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Figure 3. Common bit arrangement for content-addressable memory. 
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Figure 4. A section of a CAM. 
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the relationship of the data, it is not 
sufficient to merely dump the new 
information into its appointed storage 
location. The data currently residing in that 
location might need to merge with the 
incoming data, and the label field will 
almost certainly need to reflect the new 
information now contained in that area of 
the memory. 

Obstacles and 
advantages 

There have been a number of obstacles 
to commercially successful associative 
memories. Some of these are listed below: 

• functional and design complexity of 
the associative subsystem, 

• relatively high cost for reasonable 
storage capacity, 

• poor storage density compared to 
conventional memory, 

• slow access time due to available 
methods of implementation, and 

• a lack of software to properly use the 
associative power of the new memory 
systems. 

An associative or content-addressable 
memory is more expensive to build and has 
lower storage density than a conventional 
address-based memory because of the 
overhead involved in the storage, compari¬ 
son, manipulation, and output-selection 
logic. We demonstrate this problem in the 
section “Associative memory and proces¬ 
sor architectures.” 

Content-addressable and associative 
memories will always be more complex 
than location-addressable memories. 
Manipulation of data based on its contents, 
in association with the contents of other 
locations, entails design decisions that do 
not exist when information can be saved 
merely by address. The unfamiliarity with 
associative concepts that hampers many 
designers aggravates the situation, but 
even a widely understood CAM technol¬ 
ogy will involve the extra tasks of storage 
and retrieval by content. 

Very little software is available for 
content-addressable or associative memo¬ 
ries. It is unlikely that the programming for 
an associative memory is any more diffi¬ 
cult than that for a conventional memory; 
in fact, the programming is conceptually 
more straightforward for certain classes of 
applications. For example, an associative 
approach simplifies programs that extract 
information based on a search key, such as 


Computers supplement 
conventional memory 
systems with associative 
techniques in the form of 
cache memories and 
address-translation 
buffers. 


database utilities. 

In the end, programming for an associa¬ 
tive computer will likely differ from the 
kind of coding most software designers are 
used to writing. At some very high level of 
hierarchy, the program differences can be 
made transparent, but the lowest program¬ 
ming levels will always have to adapt to the 
underlying hardware to extract the power 
of content-based storage efficiently. An 
educational process is inevitable if soft¬ 
ware for such systems is to become gener¬ 
ally accepted. We expect that the emer¬ 
gence of economically built hardware will 
encourage software availability. 

Motivating factors. The motivation to 
overcome these obstacles is that a combi¬ 
nation of highly parallel processing tech¬ 
niques and associative storage lends itself 
to certain classes of applications. 9 For 
example, a large part of the software in 
administrative and scientific data process¬ 
ing is related to the searching and sorting 
necessary for data arrangement in a se¬ 
quentially addressed memory. This is es¬ 
pecially true in tasks such as compiling, 
scheduling, and real-time control. This 
type of housekeeping is unnecessary in a 
CAM because the data itself is used for 
retrieval and can be retrieved already 
sorted by whatever key is specified. 

A database consisting of unordered list 
structures is a perfect candidate for con¬ 
tent-addressable treatment. Because the 
CAM searches and compares in parallel, 
the time to extract information from the 
storage medium is independent of the 
length of the list. There is no need to sort or 
compact the information in the memory, 
since it can be retrieved easily based on its 
contents. This has immediate implications 
for common data manipulations such as 
collating, searching, matching, cross refer¬ 
encing, updating, and list processing. An 
associative approach can help any problem 


where the information is stored based on a 
direct association with other data items. 

This characterization suggests a vast 
array of applications that potentially would 
benefit from associative treatment. As 
examples, content-addressable and asso¬ 
ciative memories are useful for file main¬ 
tenance, pattern recognition, symbolic 
representation of information, data 
retrieval, parallel arithmetic algorithms, 
data correlation, speech recognition, radar 
analysis, connectivity testing, spelling 
checking, list and string processing, air 
traffic control, relaxation problems, and 
language translations. CAMs are es¬ 
pecially useful for computer languages 
that tend to fragment memory with their 
usage. One notable example is Lisp, which 
is commonly used to write applications in 
artificial intelligence. 

The performance improvement in many 
of the above areas can be dramatic using an 
associative memory, especially when the 
database is large and search time on a 
conventional computer becomes signifi¬ 
cant. To see this improvement, consider a 
sorting problem where each data item must 
be compared to all other data items to 
ascertain its sort position. In the general 
case, the search/sort time grows at the rate 
of O(nlogn), where n is the number of 
items on the list. An application that 
needed only the maximum value would 
grow in execution time at least as fast as the 
increase in the list size. With an appropri¬ 
ate associative memory or associative 
processor, the sorting could be done during 
the access, growing only as the list grows. 
A problem that needed only the largest 
value could inspect all the data items si¬ 
multaneously, and the performance would 
be the same for any list size that fit within 
the memory. 

New architectures. Computer systems 
already supplement conventional memory 
systems with associative architectural 
techniques in the form of cache memories 
and address-translation buffers. Content- 
addressable and associative memories will 
become even more important in new 
computer architectures. Massively parallel 
computer systems cannot depend on a 
serial memory bottleneck, but instead must 
have concurrent access to much of the 
computer database. Dataflow machines, 
for example, rely on the tags in the data 
words to route them through the system. 
Since instructions can only execute if all 
their operands are available, the pairing 
and routing of instruction operands is one 
of the most critical functions of the whole 
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system. An associative memory facilitates 
matching the tags to the proper operation 
nodes. 

Researchers at the University of 
Manchester took a slightly different ap¬ 
proach when they implemented the 
matching store of their dataflow computer 
in 1978. The largest commercially 
available content-addressable memory at 
that time was only 64 bits in size, making 
it impractical to implement a true content- 
addressable matching store. Instead, a 
pseudocontent-addressable matching 
store 10 was implemented by manipulating 
data in conventional RAM through a hard¬ 
ware hashing function unit. (See the 
sidebar entitled “Hash coding.”) 

An associative memory also would be 
appropriate in an intelligent network 
routing system, which could use the 
association of message content and routing 
information to efficiently package and 
dispatch the network intercommunication. 
Duplicate messages within local routing 
areas could be sent between the global 
routing nodes as a single message, which 
would be decoded at the receiving node 


A distributed-memory 
system, with 
variable-length 
data fields, allows 
extraction of data 
by association using 
flexible keys. 


using content-addressable techniques. 
This would reduce the traffic between the 
global nodes. An example of a device for 
such applications is Advanced Micro 
Devices’ recently introduced 256-word by 
48-bit CAM, which is optimized for 
address decoding in local area networks. 

Another possible architecture is an asso¬ 
ciative distributed-memory system, where 
a large number of identical cells are stored 
and compared in parallel. 7 - 9 This provides 


a fault-tolerant processing environment 
where single cell failures cause, at worst, a 
gradual system degradation rather than a 
catastrophic system failure. The storage in 
such a distributed system has less structure 
than that in a word-organized CAM. A dis¬ 
tributed-memory system, with variable- 
length data fields, allows extraction of data 
by association using flexible keys. The 
pattern of the associative recall of all the 
cells guides the memory response. 

Neural networks. One important 
example of a distributed associative- 
processing system is a neural network. 
This computing structure combines mas¬ 
sive parallelism, fine-grained execution 
elements, and a highly connected inter¬ 
communication topology to solve complex 
problems such as speech and image 
recognition. Many competing hypotheses 
are explored in parallel, and decisions are 
based on a combination of the existing 
links and variable weights. The neural 
network attempts to copy the functions of 
the human brain, which excels at such 
applications." 


Hash coding 


Associative memory techniques can quickly access data 
words based on their contents. However, the expense and 
size limitations of feasible associative memories has led to 
a compromise method of content-addressable access 
called hash coding. A hash coding system uses a 
traditional location-addressable memory and allows data 
to be stored and retrieved in a serial fashion, but it does 
so using the contents of the data. 

Each data entry in such a system is stored with an 
address based on some simple arithmetic function of the 
data word contents. Since an algorithm uses the entire 
word or fields within the word to calculate the mapping 
address, more than one data word might map to the same 
location in memory, causing a collision. In this case, an 
alternate location must be found for the data. Methods for 
calculating an alternate storage location include 

• searching incrementally through consecutive 
memory locations until an empty space is found, 

• creating a new hash address using a different 
algorithm, or 

• using a secondary area to store all collisions. 

The data retrieval mechanism must be deterministic and 
allied with the storage method. A data word is not acces¬ 
sible without a repeatable alternate selection algorithm, 
especially after deletion of other words originally mapping 


to the same address. Hash coding works best when the 
hashing function spreads the calculated addresses over 
memory to minimize collisions, so different arithmetic func¬ 
tions are best used for different types of databases. 

Hash coding can be improved in some situations by 
using the hash table as a pointer to the actual data 
address. This allows manipulation of the storage data by 
merely changing the pointer. When the possible memory 
map space is large, address compression can minimize 
the actual memory needed for storage. 

We can use hash coding in systems where the data are 
accessed serially and the key words are unique and error- 
free (for example, in database management problems and 
compiler symbol tables). Although most hash coding 
systems are implemented in software, researchers at the 
University of Manchester have built a hardware hashing 
system in their dataflow machine. 1 The system uses hard¬ 
ware to generate the original address and contains a 
separate overflow area for collisions. A conflict counter 
keeps track of how many data words originally map to 
each storage word, facilitating fast access to data by 
content but still allowing deletion of data. 

Reference 

1. J.G.D. da Silva and I. Watson, “Pseudo-Associative Store with 
Hardware Hashing," IEE Proc. part E. — Computers and Digi¬ 
tal Techniques. Vol. 130, No. 1, Jan. 1983, pp. 19-24. 


July 1989 


55 












Figure 5. Neural network classifier. 


Object = apple 


Attribute = color r 


Apple [ Food 


Figure 6. Direct association. 


A neural network by its nature is an 
associative processing engine. Input data 
is supplied to the network, and the output is 
either directly entered for storage or in¬ 
ferred by the system based oh a training 
score. New input information is asso- 
ciatively compared to the existing data¬ 
base, and the output response is selected 
according to the learned rules of behavior. 
Used in this manner, neural networks have 
shown some astounding results in pattern 
recognition. For example, Teuvo Kohonen 
of the Helsinki University of Technology 
has developed an associative memory that 
recognizes partially obscured images of 
faces. 12 

When used as a CAM, a neural network 
can provide the correct output when only 
part of an input pattern is available. For 
example, a partial citation might be input 
to the system, and the system would match 
and select the entire bibliographic refer¬ 
ence for output. In this function, the neural 
network classifies the input information 
based on the stored data and the input key. 

Like most concepts pertaining to asso¬ 


Figure 7. Indirect association. 


ciative memories, neural networks have 
been researched and understood for many 
years. Some notable neural networks that 
have served as associative memories are 
the Hopfield net, the Hamming net, and the 
perceptron. More recently, neurocomput¬ 
ers have reached the commercial market¬ 
place as coprocessors that plug into exist¬ 
ing computer systems. 

Figure 5 shows a neural network classi¬ 
fier. This system accepts input patterns and 
selects the best match from its storage 
database. The input values are fed into the 
matching store, which makes matches 
based on the available data. The intermedi¬ 
ate scores are then passed to the selection 
block, which filters the best match for 
output. 

The selection information is returned to 
modify the matching store data and thus 
train the associative network. The data 
interconnections that form during this 
training session become the associative 
store and provide the basis for later con¬ 
tent-driven output selection. As selections 
are made, the feedback modifies the stor¬ 


age information such that the correct asso¬ 
ciative interconnections exist within the 
neural network. 

This training session is in many ways the 
neural network equivalent of program¬ 
ming in a traditional computer system. The 
algorithmic description needed by a von 
Neumann computer is entirely inappro¬ 
priate for a neural computer. A new soft¬ 
ware technique must be created for the 
highly distributed associative-processing 
system. We discuss this topic in more detail 
in the section “Software for associative 
processors.” 

Associative storage, 
retrieval, and 
processing methods 

In an associative memory, we must as¬ 
sign state variables to conceptual items 
and the connections between them. The 
associative recall takes the form of a re¬ 
sponse pattern obtained on the output when 
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Figure 8. Relational structure using triples of indirect association. 


presented with a key pattern on the input. A 
further input in the form of a mask pattern 
includes context information that selects 
closeness of recall. In this way, a broad 
search might turn up enough information 
to allow a more narrow search using a new 
key or mask context. Many relationships 
can be considered when manipulating the 
data within an associative memory, and the 
intersection of the relevant items can be 
used for specific recall. 

The information can be linked by direct 
or indirect association. Direct association 
makes a logical link between the stored 
items. Using one of the items as a key 
causes the memory to present the associ¬ 
ated item. This method of association is 
limited. The simple example in Figure 6 
links “apple” to “food.” 

Indirect storage uses inferences to save 
information, giving an object a certain 
value for an attribute. In a simple case, 
three pieces of information can be stored 
for each set. By providing one or two of the 
pieces as a key, all three pieces can be 
accessed. 

Consider an apple with the color red, as 
shown in Figure 7. The object is “apple,” 
the attribute is “color,” and the value is 
“red.” This can be represented by the triple 
(apple, color, red). 8 By providing the value 
and the attribute ( X , color, red), we extract 
the name of the object (7f=apple). Alterna¬ 
tively, we could present the object along 
with the attribute (apple, color, X) to ex¬ 


tract the value of the color (X = red). If we 
present only the object (apple, X, Y ), the 
given response is both the attribute and the 
value (X = color, Y = red). This returns 
general information about the object. Such 
relational structures can be built up to 
create complex concepts. 13 In this ex¬ 
ample, the database could include infor¬ 
mation about other attributes (taste, feel, 
etc.) and contain other objects with sepa¬ 
rate or overlapping values. Figure 8 shows 
an example of such a system. 

Various recall methods are possible 
when using an associative memory for 
search and match operations. 13 In auto- 
associative recall, an entire stored pattern 
is recalled as a response to any subpattern 
within it. The subpattern must be large 
enough to provide the proper recall ability. 
Heteroassociative recall responds with a 
stored pattern when an input key does not 
structurally correspond to any pattern in 
the memory. The retrieval keys must be 
stored explicitly for recall in this manner. 

An associative memory system might 
use associative encoding, where a subpat- 
tem represents the entire data word. Recall 
might even be based on statistical compu¬ 
tations, where any defects in the key are 
statistically smoothed out. In all cases of 
recall, it is important that any imperfec¬ 
tions in the stored information or the key 
be corrected optimally with respect to the 
key information. 

Each of these associative recall methods 


assumes that only one internal data item 
will be selected for output. The selected 
item will be the one that best matches the 
input data. 

Hamming distance. One of the earliest 
methods of best-match retrieval was based 
on the Hamming distance devised by 
R.W. Hamming. Originally thought useful 
only for binary data, this method was later 
seen as applicable to any ordered set of 
discrete-valued elements. 6 Many com¬ 
puter systems now use Hamming error- 
correcting codes, which are based on the 
assumption that data and poise (error 
information) are random. In other words, 
no statistical basis exists for assuming that 
certain patterns will be more prevalent 
than others. If we knew, for instance, that 
a database contained only text passages, 
we could construct a more efficient, 
statistically weighted code based on the 
fact that certain letters of the alphabet are 
more likely to be used in written text than 
others. Generally there are no statistically 
relevant patterns, so the most efficient 
system allows a random data pattern to be 
encoded. 

We can construct Hamming codes to 
allow correction of any number of random 
error bits. They do so by using only a 
portion of all the data patterns possible 
given a certain number of bits in the word. 
In practice, extra check bits are added to a 
number of data bits, and the combination 
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Figure 9. Data and check bits using a Hamming code. 



Figure 10. Three-dimensional model of Hamming distance. 


of check and data bits forms the data word. 
As shown in Figure 9, the data bits are 
labeled m, the check bits k , and the total 
number of bits in the word n. 

The code’s error-detection ability is 
symmetric, in that an error in either a data 
bit or a check bit will be handled properly. 
The number of extra check bits necessary 
for the data bits depends on the size of the 
needed usable data word and the necessary 
correction capability. For example, to de¬ 
tect and correct one error bit in 32 bits of 
usable data, 7 check bits are needed; for a 
64-bit data word, 8 check bits are required. 

A geometric analysis of the same coding 
technique introduces the concept of a 
Hamming distance. If all the possible pat¬ 


terns of data and check bits are enumer¬ 
ated, only a subset is used for actual stored 
information. The legitimate information 
patterns are stored such that a data word 
with errors is geometrically closer to one 
correct data pattern than any other. We can 
picture this as a distance between legiti¬ 
mate data words, as shown in Figure 10 for 
a three-bit code. The two correct data pat¬ 
terns in this example are (0,0,0) and 
(1,1,1). The other comers of the cube are 
possible data patterns with a single bit 
error at most. The circled corners are data 
patterns that will be corrected to (0,0,0), 
and the corners with squares will be cor¬ 
rected to (1,1,1). The dotted lines form 
planes that separate the two data domains. 


An associative memory can use Ham¬ 
ming distance for inexact retrieval by al¬ 
lowing the correction process to respond 
with the closest data pattern for a given 
query key. In this case, a single response is 
possible, and any input will respond with 
some output. By choosing an appropriate 
Hamming distance between legitimate 
data words, we can construct a robust asso¬ 
ciative memory. More legitimate data pat¬ 
terns can be accommodated for the same 
number of memory bits if the system will 
accept multiple responses. In this case, 
there might be many memory words at the 
same Hamming distance in relation to the 
key word, and each of them are accounted 
for in the memory response. 

Variational similarity is another inter¬ 
esting system of retrieval by inexact 
match. 6 In this approach, a data key is 
broken into small pieces, and each piece is 
independently compared to similar pieces 
in the stored words by shifting each key 
piece relative to the stored record pieces. 
This method is useful when searching for 
local similarity. It is efficient for strings 
with small errors because it compensates 
for local distortion that leaves the rest of 
the data word intact. 

Associative memory 
and processor 
architectures 

We can group the data in an associative 
memory by words, bits, bytes, or variable 
fields. The architectural trade-offs to con¬ 
sider when deciding the orientation of the 
memory are 

• the storage medium, 

• the communication between cells, 

• the type of retrieval logic, and 

• the nature and size of external logic 
(such as registers and I/O ports). 

Three typical storage and retrieval archi¬ 
tectures are bit serial, byte serial, and word 
serial. The data in a bit-serial associative 
memory is inspected one bit at time, with 
the same bit in every word in the memory 
looked at simultaneously. The bit position 
in each memory word is handled as a slice 
running from the first memory word to the 
last. The search time through such a 
memory is related to the word width rather 
than the memory depth (number of words) 
because the entire memory depth is 
searched in parallel for each bit in the 
word. 
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Figure 11 shows a bit-serial associative 
memory. The system inspects the words in 
the memory in a bit-serial fashion using the 
key word and the mask. The data can be 
input to the memory for storage in a bit- 
serial or word-serial fashion, using the bit 
slice or word slice inputs shown. The out¬ 
put bit slice indicates which words match 
the key and mask combination, and the 
output word slice reads the actual match¬ 
ing words. 

Byte-serial associative memories in¬ 
spect a byte with each memory access, 
comparing the same byte position in every 
memory word simultaneously. Word- 
serial systems read one whole word at a 
time and cycle through all the words in the 
memory sequentially with each associative 
access. 

Another associative memory architec¬ 
ture, called a distributed logic memory, 
places the comparison and manipulation 
logic into each cell and thus truly performs 
the comparison function on every cell 
simultaneously. The information content 
of the memory is not made up of discrete 
information locations. Rather, it consists 
of information distributed throughout the 
entire memory, where all the data stored in 
the memory combines to evoke a compari¬ 
son. 

Design considerations. Memory access 
speed, system cost, and cell density are 
important design considerations when 
constructing an associative memory. The 
speed of a content-addressable or associa¬ 
tive memory depends on the access time of 
the storage elements, the cycle time of the 
system, and the degree of parallelism in the 
operation. For example, a bit-serial archi¬ 
tecture has less inherent parallelism than a 
distributed-logic associative memory. 
However, a distributed logic memory has a 
longer cycle time for each cell operation 
than a bit-serial architecture because of the 
extra logic in each cell and the intercon¬ 
nection hardware required. 

The access, cycle, and operation times 
for a particular application depend on the 
characteristics of the operation and how 
they relate to the memory architecture. The 
bit- and byte-slice architectures perform 
better on data and arithmetic computation, 
while the distributed logic architecture is 
best at equality comparisons and multi¬ 
processor control. A hybrid approach can 
be used for more general applications, al¬ 
though an associative memory or proces¬ 
sor is most useful when tuned to a particu¬ 
lar application. 

The cost of an associative memory is 
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Figure 11. Bit-serial associative memory block diagram. 


controlled by the cost of the storage ele¬ 
ments, the cell interconnection cost, and 
the amount of logic associated with each 
element. In general, a bit- or byte-serial 
architecture is less expensive than a dis¬ 
tributed logic architecture because of the 
smaller amount of logic for each storage 
element. For the same reason, a bit-serial 
system is denser than a distributed associa¬ 
tive memory system. Because of this, we 
can build a larger associative memory with 
bit-, byte-, or word-serial techniques than 
with a distributed memory. 

Stuttgen* has described a hierarchical 
associative memory system that takes 
advantage of the trade-offs between per¬ 
formance and cost. The first level of hier¬ 
archy is a fast, distributed, expensive asso¬ 
ciative memory that operates locally on a 
small amount of data. This resembles a 
cache in a traditional computing system, 
though the concept of locality probably 
does not apply since the data address is not 
meaningful. 

The next level of hierarchy is a larger, 
serial, less expensive associative store that 
contains the entire database or program. 
The main storage can be broken into parti¬ 


tions, or files, and each file is sent to the 
first level for fast processing. Another way 
of partitioning the data is a general associa¬ 
tive search of the main storage with a 
particular key and context mask. The 
number of responses from the main mem¬ 
ory can be counted and the mask or key can 
be modified until the number of respond¬ 
ing cells fits into the local memory. In this 
hierarchical associative memory system, 
fast information interchange between the 
levels is important. 

Current devices. Over the past few 
years, a number of CAM ICs have been 
designed and built. Kadota et al. 1 describe 
a content-addressable and reentrant mem¬ 
ory (CARM), an 8-kilobit content-address¬ 
able IC organized as 256 words by 32 bits 
and fabricated with two-micrometer 
CMOS technology and two-layer metalli¬ 
zation. The basic structure is similar to that 
of a static RAM in that it has address 
decoders, memory cell arrays, bit lines, 
word lines, write drivers, and sense ampli¬ 
fiers. To provide the required functional¬ 
ity, data and mask registers have been 
added along with sense lines for each word. 
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Figure 12. A block diagram of a CARM. 


an address encoder (as well as a decoder), 
and an address pointer. Figure 12 shows a 
block diagram of this device. 

The device receives 32-bit-wide data 
through the data pins and transfers it to the 
data register. This data is masked accord¬ 
ing to the condition of the bits set in the 
mask register, then applied to all the 
memory words in parallel. If the masked 
data coincides with the data stored in the 
memory words, a match occurs. In this 
case, the sense lines for those words are 
activated and the information is propa¬ 
gated to the matching sense amplifier. The 
amplifier activates the sequential address 
encoder, and the address of the correspond¬ 
ing word is output through the address bus. 
When more than one word matches the 
data applied to the device, corresponding 
addresses are output, one after another, 
from the sequential address encoder. 

Problems of early CAM devices in¬ 
cluded limited size and lack of expandabil¬ 


ity. Even with current technology, we 
cannot conceive of a single IC that satisfies 
all of a CAM’s requirements. A modular 
design is therefore essential, so we can 
easily increase memory capacity by adding 
extra, identical ICs. 

We can increase the memory width and 
depth of conventional RAM systems easily 
by adding extra memory devices. Increas¬ 
ing the size of a CAM system is not as 
simple. The most difficult expansion fea¬ 
ture concerns the label and tag fields, 
which are required for a content-address¬ 
able search. The tag field can be consid¬ 
ered an extension of the label field, but the 
design must still allow expansion of the 
width of this combined field. Also, an 
increased number of entries must be ac¬ 
commodated, corresponding to an increase 
in the depth of the memory. 

Ogura et al. 14 describe a 4-kilobit CAM 
IC, organized as 128 words by 32 bits, 
which can be interconnected to produce 


larger CAM sizes. A garbage flag register 
indicates whether a word location is empty. 
During write operations, a multiple-re¬ 
sponse resolver selects from among empty 
word locations. To implement a memory 
with more than 128 words, a number of 
these CAMs can be connected by sharing a 
common data bus. Each CAM has an in¬ 
hibit in and out signal (P txmt and P exj ). 
P euM is generated from the multiple-re¬ 
sponse resolver flag register outputs. To 
extend the word count (depth) of this 
memory, two memory chips can be con¬ 
nected on a common data bus, as shown in 
Figure 13. This produces a memory system 
with 256 32-bit words. 

Using the inhibit signals, a priority is 
assigned in a daisy-chain fashion to re¬ 
solve data-bus contention. When data is to 
be stored or retrieved from the system, 
each of the CAM modules looks for an 
empty word location by referring to the 
garbage flag register. If an empty word is 
located in a module, the inhibit signal 
(P emu ) is set to 1, which is then transferred 
to the last chip in a ripple-through opera¬ 
tion. After the highest priority module has 
accessed the common bus, its (P exo J sig¬ 
nal is set to 0, allowing the next IC in the 
sequence to have priority. 

To increase the width of the CAM, rather 
than the depth, current CAM designs (such 
as the CARM) generate an address when a 
match occurs. As an example of this 
scheme, assume that the matching opera¬ 
tion is required on 12 bits but that the actual 
width of the individual devices is only 4 
bits. The 12 bits are split into three groups 
of 4 bits, and one group is applied to each 
of the three devices. One of the devices 
acts as a master and the rest are pro¬ 
grammed to act as slaves, as shown in 
Figure 14. If the master detects a match on 
the four bits it receives, it outputs the 
address corresponding to the location of 
the matched entry. This address is then 
used as an input to all the slaves. The slaves 
compare their 4 bits of input data with the 
data stored at that particular address; if the 
stored data is the same, then an output bit 
is set. A match on the whole 12 bits only 
occurs if all the slaves indicate matches. 

The LSI CAM devices just described 
use about 10 transistors for each stored bit, 
and they are all based on a static memory 
cell model. For comparison, a dynamic 
CAM that only requires five transistors per 
cell is part of the Smart Memory project at 
MIT. 15 These devices are all substantially 
larger than the single transistor and capaci¬ 
tor required to store one bit of information 
in dynamic RAM. 
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Software for 
associative processors 


Common data bus 



Figure 13. Two memory chips connected on a common data bus to increase the 
word count of CAMs. 
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Label 



Figure 14. A CAM arrangement that increases the width of the label field. 


Storage, retrieval, and manipulation 
concepts for associative memories and 
processors differ greatly from those used 
on traditional computers. 

An example is a typical computer in¬ 
struction such as “store X” which pre¬ 
sumably takes a value from an internal 
register and stores it in a memory location 
with address X. We cannot directly com¬ 
pare this with an associative processor 
because an associative memory contains 
no location addressed by X, only locations 
differentiated by their contents. Depend¬ 
ing on the exact implementation of the 
associative system, this type of instruction 
might refer to a pattern X, but it is still 
unclear what function would be performed. 

The instruction becomes even less ap¬ 
propriate on a distributed-logic associative 
processor, such as a neural network. In this 
case, the value or pattern is essentially 
spread over the entire memory and cannot 
be uniquely addressed. A new language 
description seems necessary to account for 
the new architecture implied by associa¬ 
tive processing. 

A well-designed high-level language 
should not depend on the data-storage 
mechanism and can shield the user from 
some of the differences of an associative 
system. However, fully exploiting the 
power of fast, parallel, content-related data 
management requires that the programmer 
have some knowledge of the underlying 
associative architecture. At some level, the 
software language must contain the proper 
syntax and program flow control to effi¬ 
ciently execute applications on the asso¬ 
ciative hardware. 

An analogy in a traditional program¬ 
ming language is an optimizing compiler. 
For example, most popular C compilers 
have some optimization built into the 
translation from high-level language to 
machine code. Loops become more effi¬ 
cient, unnecessary instructions are re¬ 
moved, and entire sections of code often 
change completely to provide a faster or 
smaller program. However, the underlying 
sequential nature of the language remains 
intact. 

Using this same technique, software 
written for associative systems can pro¬ 
vide a high-level interface that assumes 
that the compiler and hardware will some¬ 
how translate the application description 
into an efficient program. The programmer 
will have to understand the parallel and 


associative nature of the program, but will 
not worry about the exact details of the 
translation. 

The emerging field of parallel process¬ 
ing is one area where an associative mem¬ 
ory can substantially enhance a computing 
system. For example, the Linda parallel 
processing language relies on “tuple 
space” to coordinate the multiple execu¬ 
tion threads. The tuples formed in this 


language are matched by associative com¬ 
parison rather than address. 16 This lan¬ 
guage obviously benefits from an associa¬ 
tive component. 

Many new programming languages in 
artificial intelligence are nonprocedural. 
We hope these languages will more closely 
model how people deal with problems. 
Languages such as Prolog and Smalltalk 
identify objects and their interrelation- 
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ships, and are good prospects for an asso¬ 
ciative processor. 

Databases. Associative and content- 
addressable systems show good short-term 
promise as fast, efficient database engines. 
The software to implement this function 
must provide easy, context-sensitive 
searches on sometimes unstructured data, 
and the user interface must be accessible to 
the average programmer. (To properly 
understand the software used on such data¬ 
base systems, see the sidebar “General 
concepts of database theory.”) 

The field of relational database manage¬ 
ment has grown quickly, and the American 
National Standards Institute (ANSI) has 
recently approved Structured Query Lan¬ 
guage as a standard relational database 
programming interface. This shows how a 
high-level associative language can drive a 
generalized architectural description. The 
hardware in question will come from many 
different vendors, who will structure their 
actual system architectures differently but 
who will each allow SQL-based software 
to function. 


Associative and 
content-addressable 
systems show good 
short-term promise 
as fast, efficient 
database engines. 


Hypertext. Another new and exciting 
concept in data access, called hypertext, 
changes the traditional relationships be¬ 
tween data structures. Instead of accessing 
information based on its linear organiza¬ 
tion, this retrieval method accesses data 
based on nonlinear links between chunks 
of information. Hypertext is currently 
under investigation as a teaching and re¬ 
trieval method. 17 

Hypertext provides a perfect platform 
for an associative processor. In fact, hy¬ 


pertext has already been expanded to in¬ 
clude nontext entities, such as graphics, 
digitized speech, audio recordings, anima¬ 
tion, and pictures. The more general term 
“hypermedia” might even include tastes, 
odors, and tactile sensations. The more 
complex and varied the hypertext/hyper- 
media systems become, the more useful a 
fast and easily programmed associative 
system becomes. 

Hypertext programming specifies the 
links between data chunks. This resembles 
the content-addressable memory scheme 
described earlier, where a label is used to 
retrieve the associated data. At each posi¬ 
tion in the hypertext system, the possible 
next links can be programmed by associat¬ 
ing the appropriate label fields. In a gen¬ 
eral hypermedia system, the programming 
is more varied but substantially the same. 
The associative program would add the 
correct associative links depending on the 
available media paths at each node. 

Distributed-logic associative memo¬ 
ries. We have referred to distributed-logic 
associative memories several times. The 


General concepts of database theory 


A database system stores information as objects, or 
entities, that have descriptive characteristics called 
attributes. The entities have associations with one 
another, and combining associations leads to a 
relationship. For example, a mechanic might have taken a 
particular course, and the two entities of “mechanic" and 
“course” form an association. The mechanic’s grade in 
that course would be an attribute of the relationship. 

In a one-to-many relationship, an entity has a relation¬ 
ship to potentially many other entities, but the latter 
entities have a relationship with only one of the former 
entities. A many-to-many relationship, which is the 
scheme of most interest to an associative system, allows 
any number of entities to have relationships with one 
another. 

The three database models in use today are the 
hierarchical, network, and relational systems. A relational 
database model, the newest of the three structures, 
overcomes the record-oriented limitation of the hier¬ 
archical and network descriptions. It allows many-to-many 
relationships without pointer overhead. Since the informa¬ 
tion is not stored with a predefined structural relationship, 
the relational model is most appropriate for implementa¬ 
tion as an associative processing system. 

The relational database relies on a mathematical 
language called relational algebra, or relational calculus, 
that describes a set of operations possible on an 
associative memory. 1 The data in the memory are 


modeled as tables, sometimes called relations, composed 
of rows and columns. The rows in the table are called 
tuples, and the columns are referred to as attributes. The 
relationships between the data cells are considered sets. 
The available operations are: 

• Form subsets of rows or columns. 

• Form the union, difference, or intersection of sets. 

• Combine relations by concatenating sets. 

A relational database management system uses 
relational algebra to provide a practical database imple¬ 
mentation. The data cells within the system are not 
positionally related to one another. In this way, the 
database is examined as a table of information, and the 
programmer does not have to be concerned with how the 
data is actually stored. 

New tables are created by using relational algebra to 
extract the rows and columns of current interest. Multiple 
relationships can be described by combining several 
tables into one. The programmer can selectively mask out 
certain rows or columns and allow only contextually rele¬ 
vant information to be extracted for manipulation. 

Reference 

1. H.J. Stuttgen, A Hierarchical Associative Processing System, 
Springer-Verlag, Berlin, 1985. 


62 


COMPUTER 












software needed to program these systems 
can only marginally be considered soft¬ 
ware at all. We will use a neural network, 
the best example of such a memory system, 
to describe the programming, which modi¬ 
fies the connections between the primitive 
storage elements. Systems created for this 
purpose are called connectionist , 18 

The programming of a connectionist 
computing system is more akin to teaching 
than to what is normally considered 
programming. The learning process is 
accomplished by entering initial input data 
and feeding the selected outputs back into 
the teaching inputs. The associative neural 
network decides which stored pattern most 
closely matches the input vector and 
selects an output based on the best match. 
The programming of connectionist 
systems, still a topic of research and 
debate, depends on the associated 
hardware. The information in the neural 
system can be stored as a local or 
distributed representation. 

In a local representation, each discrete 
packet of data is localized to a section of 
the hardware. This is the easier of the two 
representations to program, since most of 
the neural nodes interact very little. It is 
also more familiar to programmers in that 
the individual chunks of information can 
be stored and validated without regard to 
the rest of the stored data. However, it 
allows many single failure points; if the 
local area used to store a piece of informa¬ 
tion is broken, that information is no longer 
available for recall. 

A distributed representation spreads the 
data throughout the available hardware. 
Every neural node in the processing struc¬ 
ture is potentially activated when any data 
is input. This eliminates any single failure 
point and creates the most reliable associa¬ 
tive system possible in terms of hardware. 
The disadvantage to the completely dis¬ 
tributed representation is the programming 
and validation obstacle it presents to a 
software engineer. Since every execution 
and storage unit can be involved with every 
recall attempt, unexpected connections 
can influence the decision process. 

No single software architecture can 
program the varied, and sometimes incom¬ 
patible, systems that we can implement 
using associative concepts. Indeed, we 
will need a combination of hardware and 
software to design popular, easy-to-use as¬ 
sociative computers. An associative com¬ 
puter system might have several associa¬ 
tive memory subsystems, each interacting 
with sequential execution units. 

Sequential and parallel techniques un¬ 


doubtedly will coexist in programming, 
since different applications will always 
have sections where one method provides 
obvious benefits. In the same way, a com¬ 
bination of location-addressable and asso¬ 
ciative systems will probably provide an 
efficient mechanism to execute most appli¬ 
cations. Optimizing compilers and new 
methods of flow control and scheduling 
must provide a consistent interface to the 
programmer, while translating the pro¬ 
grams to execute efficiently on the associa¬ 
tive system. In this way, the computing 
systems will realize a performance gain 
commensurate with the extra hardware and 
development cost needed to implement an 
associative processor. 


T he concepts and techniques of 
content-addressable and associa¬ 
tive systems are already appearing 
commercially and will become more 
important as the technology to build 
devices reduces the size and cost of the 
final systems, and as more people become 
familiar with these systems. We hope this 
article has provided motivation for people 
to consider applying associative concepts 
to both current and future problems, thus 
accelerating the progress already 
underway, & ‘ ( 
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A Survey of Synchronization 
Methods for Parallel 
Computers 

Anne Dinning 
New York University 


T he growth of multiprocessors is 
evidence of an increasing focus on 
achieving high program speeds 
through parallelism. One of the primary 
problems confronting designers of mul¬ 
tiprocessors is to provide efficient synchro¬ 
nization methods. The concurrent 
execution of programs may be limited by 
the parallelism exhibited in the control 
mechanism and by the associated over¬ 
head. A family of effective synchroniza¬ 
tion concepts can aid in the design and 
construction of parallel programs. 
Although synchronization is a long¬ 
standing area of research, existing solu¬ 
tions must be readdressed in the context of 
specific constraints posed by general- 
purpose, multiple-instruction, multiple- 
data (MIMD) architectures. 

This article examines how traditional 
synchronization methods influence the 
design of MIMD multiprocessors. This 
particular class of architectures is one in 
which high-level synchronization plays an 
important role. Although vector proces¬ 
sors, dataflow machines, and single¬ 
instruction, multiple-data (SIMD) com¬ 
puters are highly synchronized, their syn¬ 
chronization is generally an explicit part of 
the control flow and is executed as part of 
every instruction. In MIMD multiproces¬ 
sors, synchronization must occur on 
demand, so more sophisticated schemes 


Efficient synchroniza¬ 
tion is essential to 
parallel processing. 
Today’s MIMD 
multiprocessors 
demand sophisticated 
implementations of 
traditional synchroni¬ 
zation methods as 
fundamental parts of 
their designs. 


are needed. 

Synchronization must be an integral 
part of a multiprocessor system for several 
reasons. Many pure software solutions, 
such as Dijkstra’s n-process mutual- 
exclusion primitives for controlling access 
to a critical section, are designed for a spe¬ 
cific number of processes and are not 
appropriate for general-purpose synchro¬ 


nization. In addition, it is possible to 
decrease bus or network contention and 
CPU usage by moving the synchronization 
logic “closer” to the memory Units and 
providing a separate controller to perform 
synchronization. Moreover, synchroniza¬ 
tion has a large influence on the parallel¬ 
programming environment. It controls the 
granularity of efficient parallelism, 
influences the ease of writing correct pro¬ 
grams and proving them correct, deter¬ 
mines the fairness of selection among 
competing processes, and affects the effi¬ 
ciency of parallel-program execution. 
Because most, if not all, programs 
designed to run on a multiprocessor are 
parallel, this influence is felt by virtually 
all applications. Thus, synchronization 
has a much stronger impact on system per¬ 
formance of multiprocessors than of 
uniprocessors. 

The multiprocessors discussed in this 
article—the BBN Butterfly, the Cedar, the 
HEP, the HM 2 p, the Sequent, the Trans¬ 
puter, and the Ultracomputer—were 
selected because of their common goal to 
perform efficient synchronization by spe¬ 
cial hardware, sophisticated software, or 
a combination of the two. For a more 
complete explanation of the synchroniza¬ 
tion problem, many excellent articles and 
books are available—see, for example, 
Andrew and Schneider’s survey. 1 
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Overview 

A parallel program is a set of concur¬ 
rently executing sequential processes. 
These processes cooperate and/or com¬ 
pete while executing, either by sharing var¬ 
iables or by explicitly exchanging 
information. For example, a window- 
oriented spreadsheet program can be 
implemented as a parallel program. One 
sequential process is associated with the 
spreadsheet window and another with the 
chart window; the spreadsheet data used 
by the two processes is maintained in 
shared variables. However, if the charting 
and spreadsheet processes simultaneously 
try to update a variable containing a 
column heading, the value of this variable 
may be inconsistent with either update. To 
maintain data consistency, access to 
shared variables must be controlled. 

There are several ways to control access. 
Access is mutually exclusive if no two pro¬ 
cesses access a shared variable simultane¬ 
ously. A critical section is an instruction 
sequence that has mutually exclusive 
access to shared variables. Consider what 
happens when two processes, P, and P 2 , 
concurrently execute the statement i — i + 
1, with the shared variable / originally hav¬ 
ing a value of 5. Suppose both processes 
read i before either updates it: P, reads i, 
P 2 reads /, Pi increments i and writes it, 
and finally P 2 increments / and writes it. 
This will cause the incorrect value 6 rather 
than 7 to be stored in /'. To prevent this, we 
must make access to i mutually exclusive 
by enclosing the statement /•*-/+ 1 in a 
critical section. This guarantees that the 
read, increment, and write operations are 
performed indivisibly. In general, the cor¬ 
rect use of shared variables requires that 
they be accessed from within a critical 
section. 

Processes also may need to wait until a 
set of variables is in a specific state before 
proceeding. This type of coordination, 
known as conditional synchronization, 
ensures that the variables are in a state con¬ 
sistent with the operations to follow. In the 
spreadsheet parallel program, for exam¬ 
ple, when the spreadsheet process changes 
the spreadsheet data, it notifies the chart¬ 
ing process by adding messages to a mes¬ 
sage queue. The charting process has to 
delay executing a dequeue operation if the 
message queue is empty. Waiting for the 
message queue to be “non-empty” is an 
example of conditional synchronization. 

Mutual exclusion can be guaranteed on 
a uniprocessor by disabling interrupts. 


However, this method is not sufficient in 
a multiprocessing environment. Access 
must be controlled by a set of algorithms 
called synchronization protocols. There 
are several general strategies for imple¬ 
menting synchronization protocols. Busy 
waiting, also known as continual retry, 
requires that the value of shared synchro¬ 
nization variables be repeatedly checked 
until they reach a desired state. Providing 
conditional synchronization in this man¬ 
ner is fairly trivial; a process tests the var¬ 
iables, looping until the condition is 
fulfilled, and then proceeds. Using busy 
waiting to provide mutual exclusion is 
more difficult; the algorithms must be 
encoded carefully to eliminate all race con¬ 
ditions. In addition, forcing processes to 
“spin” on the CPU, continually checking 
variable states, wastes processor power 
and may cause a flood of memory 
requests, leading to contention problems 
on the shared-memory bus or network. 
One benefit of busy waiting is that a pro¬ 
cess learns of any change of state in a syn¬ 
chronization variable very quickly, 
decreasing the overall synchronization 
time. 

In a protocol based on positive wake- 
up, a process blocks itself until it is sig¬ 
naled that a certain condition is true. This 
condition will remain true until the sig¬ 
naled process resumes execution. Positive 
wake-up requires much stronger system 
support than busy waiting; the system 
must provide a mechanism for detecting 
when a condition is met, a means of select¬ 
ing among the waiting processes, and a sig¬ 
naling mechanism. In a hybrid of busy 
waiting and positive wake-up, signaled 
retry, a process blocks itself waiting for a 
condition; when the process is signaled, it 
rechecks the condition and either proceeds 
or reblocks itself. Because of the cost of 
blocking and signaling processes, positive- 
wake-up implementations generally have 
a synchronization rate limited to once 
every few hundred instructions. 

In 1971 Dijkstra introduced four basic 
requirements for synchronization pro¬ 
tocols: 

(1) The solution must be symmetric 
among the processes; as a result we are not 
allowed to introduce a static priority. 

(2) Nothing may be assumed about the 
ratio of the finite speeds of the processors; 
we may not even assume their speeds are 
constant in time. 

(3) If any of the processes is stopped 
somewhere in “remainder of cycle” [in 
other words, not synchronizing], this is not 


allowed to lead to potential blocking of 
any others. 

(4) If more than one process is about to 
enter its critical section, it must be impos¬ 
sible to devise for them such finite speeds 
that the decision to determine which of 
them will enter its critical section first is 
postponed until eternity. In other words, 
constructions in which “After you”— 
“After you”—Blocking, although 
improbable, is still possible, are not 
regarded as valid solutions. 2 

It has become clear to people develop¬ 
ing synchronization protocols that these 
four requirements are insufficient; several 
other criteria must be met to provide a 
practical solution. 

Perhaps the most essential attribute of 
a synchronization protocol is an efficient 
implementation. The amount of time 
spent synchronizing partly determines the 
appropriate level of parallel granularity. 
Consider a parallel algorithm for adding 
two N x A matrices. If the synchroniza¬ 
tion in the algorithm requires more time 
than performing N 2 additions, adding the 
matrices serially is more efficient. More¬ 
over, a synchronization method should 
not use excessive resources. Although 
algorithms based on busy waiting allow 
synchronization with little delay, they 
waste memory bandwidth and processor 
cycles that other processes could use. 

A protocol may also need to meet a fair¬ 
ness criterion. Possible types of fairness 
include the following: 

• FIFO: No process that makes a 
request after a process b will proceed 
before b. 

• Bounded: The number of turns a pro¬ 
cess will miss after making a request 
is bounded in advance. 

• Livelock-free: One requesting process 
will always proceed; not all request¬ 
ing processes will wait forever after 
making a request. 

There is a trade-off between cost and 
fairness. In general, the higher levels of 
fairness correspond to more expensive 
implementations. Although FIFO fairness 
guarantees that no process will be served 
out of turn, its associated costs in algorith¬ 
mic complexity and memory usage may be 
too high if a less stringent level of fairness 
is acceptable. 

Another important attribute of a syn¬ 
chronization protocol is ease of correct 
use. Because parallel programs are diffi¬ 
cult to write, a mechanism should provide 
as much automated control as possible. 
Ease of use also encompasses the ability to 
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Table 1. A comparison of multiprocessor synchronization. 


Architecture 

Synchronization 

Method 

Implementation 

Method 

Resource 

Wastage 

Fairness 

Correct 

Use 

Deadlock 

Management 

Ultracomputer 

Semaphore (Fetch&Add) 

Busy wait 

CPU + network 

Livelock-free 

Difficult 

No 

Cedar 

Semaphore (ReadTestWrite) Busy wait 

CPU + network 

Livelock-free 

Difficult 

No 

Sequent 

Semaphore (Test&Set) 

Busy wait 

CPU 

Livelock-free 

Difficult 

No 

HM 2 p 

Monitor 

Positive wake-up 

None 

FIFO 

Provable 

Yes 

HEP 

Message passing 

Busy wait 

Network 

Livelock-free 

Moderate 

No 

Butterfly 

Message passing 

Positive wake-up 

None 

FIFO 

Moderate 

Possible 

Transputer 

Message passing 

Positive wake-up 

None 

FIFO 

Moderate 

Possible 


prove parallel programs correct. Hoare 
has suggested an axiomatic approach for 
proving programs correct and has incor¬ 
porated it in several synchronization 
schemes, including the monitor mecha¬ 
nism discussed later in this article. 3 Brief¬ 
ly, the axiomatic proof technique is based 
on the concept of associating precondition 
P and postcondition Q predicates with a 
sequence of statements R. If P holds 
before the execution of R, then Q must 
hold upon its completion. A proof consists 
of deducing that an assertion is true at a 
given point in the execution by applying 
rules of inference to the basic precondi¬ 
tions and postconditions. For concurrent 
programs, these proofs must also show 
that the assertion of one process cannot be 
invalidated by the execution of other pro¬ 
cesses. 

Another aspect of correctness is the abil¬ 
ity to prevent or detect deadlock. A set of 
processes is in a deadlock when the pro¬ 
cesses are all waiting for an event that will 
never occur. Consider two processes, Pi 
and P 2 , and two resources, x and y. Sup¬ 
pose process Pi has mutually exclusive 
access to resource x and is attempting to 
obtain it fory. If process P 2 has mutually 
exclusive access to resource^ and attempts 
to obtain it for x, processes Pi and P 2 will 
deadlock. 

The following sections introduce several 
traditional synchronization methods and 
discuss how they have been integrated in 
the design of several multiprocessors. The 
methods presented—semaphores, moni¬ 
tors, and message passing—and their 
implementations in the various architec¬ 
tures will be evaluated in terms of the 
criteria described above. Table 1 gives an 
overview of the multiprocessors. 


Semaphore-based 

implementations 

A semaphore is a nonnegative integer 
variable that can be accessed by two 
atomic operations 2 : 

P ( s ): Delay the calling processes 
until s > 0 and then execute 

K(s): Execute s*~ 5+ 1 

Semaphores are used for both mutual 
exclusion and conditional synchroniza¬ 
tion. Semaphores that have possible values 
of 0 and 1 are called binary semaphores. 
Those that can take the values 0 to n are 
general or counting semaphores and are 
useful when there are multiple identical 
instances of a shared resource. When a 
semaphore has a value greater than 0, it is 
defined open-, otherwise it is closed. 

To provide mutual exclusion, a sema¬ 
phore s is associated with a critical section 
and is used to guarantee sequential access 
to it. Before entering the critical section, 
each process must execute P(s)\ upon exit¬ 
ing, it must execute K(s). To perform con¬ 
ditional synchronization, a semaphore is 
associated with each condition: a process 
executes K(s) on the semaphore when it 
sets the condition to true. Conditional syn¬ 
chronization can also be performed by 
associating a semaphore with each pro¬ 
cess. When a process is waiting for a con¬ 
dition, it performs a P operation on its 
private semaphore; a signaling process will 
perform a V when a condition becomes 
true. 

Semaphores are classified as weak and 
strong on the basis of their underlying 
implementations. One way of implement¬ 


ing semaphores is busy waiting. When per¬ 
forming a P operation on a weak 
semaphore, a process repeatedly checks 
the value of the semaphore until it is 
greater than zero; at that point the process 
decrements the semaphore, verifies that 
this decrement was a legal action, and pro¬ 
ceeds. A V operation simply increments 
the semaphore. The atomicity of these 
actions must be enforced by a lower-level 
lock. In general, weak semaphores have 
very small delays but waste processor and 
memory network bandwidth that could be 
used by other processors. Moreover, many 
weak-semaphore implementations provide 
only livelock-free fairness; they do not 
guarantee that a process will not loop 
indefinitely while other processes enter the 
critical section. 

Strong semaphores are an alternative 
implementation using positive wake-up. 
To ensure that processes enter the 
critical section in a first-in-first-out 
manner, strong semaphores often use 
queues for maintaining the set of blocked 
processes. If a process executing a P(s) is 
delayed, it will be put on the queue for 
semaphore s. Otherwise it closes the sema¬ 
phore and enters the critical section. If a 
process executes a K(s) and v’s queue is not 
empty, one process will be signaled. Other¬ 
wise it opens the semaphore. Queue 
management in a multiprocessor scenario 
is another synchronization problem. 

The fundamental flaw of semaphore- 
based synchronization is that it puts the 
responsibility for controlled access on the 
programmer, who must decide when to 
synchronize and on what conditions. 
Semaphores provide no automatic 
enforcement of mutually exclusive access 
to shared variables; by mistake a program¬ 
mer may fail to include all references to 
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Figure 1. An omega network with eight processors. The double line denotes the route from processor 001 to memory module 
Oil; each switch routes a message by examining and deleting the low-order bit of the destination address. 


shared variables in critical sections. A for¬ 
gotten P or V can quickly deadlock a pro¬ 
gram. Synchronization code may be 
sprinkled throughout the program. Unless 
code is carefully structured, programs 
using semaphores are very difficult to 
understand, to code, and to prove correct. 

Three multiprocessors—Ultracomputer, 
Cedar, and Sequent—support weak sema¬ 
phores as the fundamental means of syn¬ 
chronization. The first two systems 
provide powerful multiple-operation 
memory access instructions to aid in the 
design of synchronization code. The third 
uses a special controller and network for 
synchronization. 

Ultracomputer. The NYU Ultracom¬ 
puter and IBM’s RP3 are two closely 
related architectures. 4,5 Both designs con¬ 
sist of 8 to 4,096 processors, the same 
number of memory modules, and an 
omega combining interconnection net¬ 
work (Figure 1) for access to shared 
memory. 

The combining network, made up of 
2x2 switches, provides a set of powerful 


memory access instructions for efficient 
synchronization. Fetch&Add is a multiple- 
operation memory access instruction that 
is instrumental in the creation of synchro¬ 
nization routines. It indivisibly adds a con¬ 
stant to a memory location and returns the 
previous value: 

Fetch&Add(variable, expression): 
temp «- variable 

variable •*- variable + expression 
return temp 

During one memory access cycle, any 
number of processes can access the same 
memory location. All accesses are per¬ 
formed simultaneously, the result being 
identical to the result obtained if the 
instructions were executed serially in some 
unspecified order. In addition to 
Fetch&Add, the RP3 supports several 
other multiple-operation instructions. 

The primary synchronization routines, 
busy-waiting and interrupt-based sema¬ 
phores, rely on the power of the 
Fetch&Add instruction for efficient imple¬ 
mentation. The following is the code for 
a busy-waiting semaphore: 


P(s ): while 

(Fetch&Addfs, — 1) < 0) 
Fetch&Add(s, 1) 
while (s < 0) loop 
end while 

K(s): Fetch&Addfs, 1) 

If the semaphore is open, very few 
instructions must be executed to perform 
a P operation. A V operation requires only 
one instruction. If processes are waiting 
for the semaphore to open, all can attempt 
to close it; they find out whether they suc¬ 
ceeded or not in the next memory cycle. 
This same code can be used to implement 
a counting semaphore; the semaphore s 
simply is initialized to n. 

Synchronization code on the Ultracom¬ 
puter takes advantage of the powerful 
instruction set, but this approach has 
several problems. By using busy waiting, 
it introduces all the problems of weak fair¬ 
ness and poor resource use. Although the 
omega network attempts to minimize these 
problems by combining memory requests 
to the same variable, a flood of memory 
accesses may quickly generate a “hot 
spot,” leading to network congestion. 
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Figure 2. The Cedar system and cluster organizations. 6 


Because it extends the way shared vari¬ 
ables can be safely accessed, the great 
strength of the Fetch&Add primitive is for 
the development of critical-section-free 
algorithms that eliminate the need for syn¬ 
chronization. For example, the critical sec¬ 
tion described earlier—two processes 
incrementing a shared variable i —could be 
implemented in a fully parallel manner by 
executing Fetch&Add(/', 1). Fetch&Add 
has been instrumental in the implementa¬ 
tion of many bottleneck-free parallel- 
access data structures (such as the parallel- 
access queue 4 ), which form the basis of 
many user applications and are an integral 
part of the Ultracomputer’s parallel oper¬ 
ating system. 

Cedar. The Cedar multiprocessor, an 
MIMD processor developed at the Univer¬ 
sity of Illinois in conjunction with the Cen¬ 
ter for Supercomputing Research and 
Development, provides a set of instruc¬ 
tions similar to the Ultracomputer’s 
Fetch&Add. The Cedar architecture has a 
shared global memory, a global packet- 
switched shuffle exchange network, and 
several processor clusters (Figure 2). 6 A 
processor cluster consists of four to eight 
processors, the same number of local 
memory units, a local interconnection net¬ 


work (implemented by a crossbar), and a 
local control unit. 

Synchronization is provided through a 
ReadTest Write instruction, which accesses 
specific shared variables. This instruction 
is closely based on a method developed by 
Yew and Zhu, 7 who considered the 
schemes used in the Ultracomputer and the 
HEP insufficient; on complex data depen¬ 
dency these schemes are both too primitive 
and inefficient. The ReadTestWrite 
semantics are shown in Figure 3. 

Each of Cedar’s global memory con¬ 
trollers has a rudimentary ALU, which 
compares key values, performs the oper¬ 
ations indivisibly if the condition is true, 
and returns the condition. If no data oper¬ 
ations are performed (that is, if only key 
operations are performed), a ReadTest¬ 
Write instruction can operate on any 
integer in shared memory. An extension to 
the C language supports this capability by 
defining a new variable type, keyed, and 
an operation, sync, which corresponds to 
the ReadTestWrite instruction and returns 
the value of the condition. Busy-waiting 
semaphores can easily be implemented by 
the sync operation: 

P(s ): while (sync(s = 1, decrement, 
null) = false) loop 

K(s): sync(«K//, increment, null) 


This use of sync has many of the same 
benefits and drawbacks as the Fetch&Add 
instruction. Like Fetch&Add, the primary 
benefit of sync is that it extends the use of 
shared variables without synchronization. 
Because the sync operation is more power¬ 
ful than Fetch&Add, it can be used in sim¬ 
pler synchronization algorithms. 

The main weakness of the Cedar imple¬ 
mentation is that the network to global 
memory does not combine references to 
the same variable. Therefore, all refer¬ 
ences must be serialized, and contention 
for network bandwidth may increase. 

Sequent. The Sequent Balance/21000, 
a member of a commercially available 
family of MIMD shared-memory 
machines, supports weak semaphores with 
a technique different from the multiple- 
operation instructions of the Ultracom¬ 
puter and Cedar multiprocessors. The Bal¬ 
ance/21000 has up to 30 processors, 
connected by a bus to shared memory. 8 
Its main point of interest is the system link 
and interrupt controller chip (Figure 4), 
designed by Sequent to solve many of the 
problems typically encountered in build¬ 
ing a multiprocessor. A SLIC chip is cou¬ 
pled with each major component in the 
system (memory controller, processor, 
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and I/O controller) and supports interrupt 
distribution, low-level mutual exclusion, 
configuration, and error control. The 
SLIC chips communicate through a sepa¬ 
rate SLIC bus by means of a simple 
message-passing protocol. 

The SLIC chip provides a set of 64 
single-bit gate registers and operations that 
can be used for synchronization. Each 
SLIC chip maintains a local copy of all the 
gates. When a gate status changes because 
of a successful lock-gate or unlock-gate 
instruction, a message is transmitted over 
the SLIC network, notifying all SLIC 
chips to update their local copies. Hence, 
local copies are always consistent. When 
a process performs a lock-gate instruction, 
it first checks its local copy. If the gate is 
closed, the operation fails; if it is open, the 
SLIC sends a message attempting to lock 
the gate. If multiple chips request simul¬ 
taneously, only one will succeed and the 
rest will fail. The following is the code for 
implementing a busy-waiting semaphore: 

F\s): while (lock-gate(s) = failure) loop 

K(s): unlock-gate(s) 

The advantage of this approach over the 
two previously described implementations 
is that it does not use main memory band¬ 
width for synchronization. Spinning takes 
place on a local SLIC register, not across 
the SLIC bus, keeping the bus free to per¬ 
form other support functions. However, 
processes must still spin on the CPU as 
they repeatedly attempt to lock the SLIC 
gate. 

Because each SLIC chip has only a small 
number of gates, their use is limited. To 
minimize this problem, the operating sys¬ 
tem provides spin locks and counting 
semaphores, which use gates only to 
achieve mutually exclusive access to syn¬ 
chronization variables. Multiple locks can 
share the same gate because a gate is 
needed for only the few instructions 
required to modify a synchronization var¬ 
iable. However, these protocols once again 
introduce the problem of bus contention 
by requiring that processes traverse the 
system bus while checking the status of a 
synchronization variable. 

The support provided for synchroniza¬ 
tion by the systems presented so far is of 
a fairly low level. The protocols are only 
livelock-free; a process can wait 
indefinitely before being allowed to enter 
the critical section. None of the systems 
provide any mechanism for deadlock 


if condition then 

perform data operation 
perform key operation 
endif 
where 

—condition is one of <, >, = , =£, <, > relation with the current key 
value and a parameter as operands 
—data operations include fetch, store, and no-op 
—key operations include fetch, store, increment, decrement, 
increment&fetch, decrement&fetch, and no-op 


Figure 3. The ReadTestWrite synchronization instruction used by the Cedar multi¬ 
processor. 


prevention or detection. All waste some 
resources by using busy waiting rather 
than positive wake-up or signaled retry. In 
the following sections we consider higher- 
level constructs, which hide more of the 
implementation details, taking some con¬ 
trol away from the programmer. 

Monitor-based 

implementations 

Monitors are based on the concept of 
encapsulating the state of a shared 
resource with the operations that manage 
it. 9 A monitor consists of a collection of 
variables representing a shared resource’s 
state, condition variables, temporary var¬ 
iables, procedures that perform operations 
on variables, and initialization procedures. 
Variables defined within a monitor can be 
accessed only by that monitor’s proce¬ 
dures. Only one process can be executing 
in a monitor at any time. Thus, the execu¬ 
tion of a monitor procedure guarantees 
mutually exclusive access to all monitor 
variables. 

Conditional synchronization is pro¬ 
vided by a signal-wait mechanism. When 
a process waits on a condition variable, it 
relinquishes the monitor until it is signaled. 
When a process signals a condition vari¬ 
able, it chooses a process waiting for the 
condition and activates it. The monitor 
remains locked and the signaling process 
is suspended until the newly activated pro¬ 
cess leaves the monitor or performs 
another wait operation. The example in 



Figure 4. The Sequent SLIC chip 
(adapted from B. Beck and B. Hasten 8 ). 


Figure 5 shows how a monitor can be used 
to implement one-buffer producer/con¬ 
sumer primitives. The basic protocol is 
that when the buffer is empty, all con¬ 
sumers must wait; when it is full, all 
producers must wait; and no two processes 
can access the buffer simultaneously. 

A monitor, if used with care, is a power¬ 
ful synchronization tool. Monitor pro¬ 
grams are easily understood because all the 
operations modifying shared objects 
appear in the monitor definition; the user 
of a monitor can ignore implementation 
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Producer-Consumer: monitor 
begin 

buffer is the shared data buffer 
is-full is a boolean 
empty and full are conditions 
procedure produce(£fea) 

begin 

if (is_full) then 
wait(empO') 
endif 

buffer — data 
is-full *- true 
signal (full) 

end 

procedure consume(dafa) 

begin 

if (not is_full) then 
wait(/w//) 
endif 

data *- buffer 
is-full *- false 
signal(ewp/y) 

end 

initialize 

is-full *- false 

end 


Figure 5. Monitor implementation of 
producer/consumer primitives. 


details (and the implementer can ignore 
usage). Writing correct programs is simpli¬ 
fied by the fact that access to shared vari¬ 
ables can be only mutually exclusive, an 
improvement over the ad hoc control 
provided by semaphores. Hoare’s method 
of axiomatic proof can be applied to pro¬ 
grams using monitors. Preconditions and 
postconditions can be associated with each 
procedure call, initialization routine, and 
signal and wait operation. 

Monitors are implemented with positive 
wake-up; processes delayed when entering 
or within the monitor are put on a queue. 
Thus, monitors achieve bounded fairness 
by utilizing FIFO queues as the underlying 
data structure. Because of these strengths, 
the HM 2 p multiprocessor bases its syn¬ 
chronization scheme on the monitor 
mechanism. 

However, several problems are inherent 
in the mechanism. If monitor calls are 
nested, processes may become dead¬ 
locked. Suppose we have two monitors, A 
and B, such that a procedure a in A con¬ 


tains a call to a procedure in B, and a 
procedure b in B contains a call to a proce¬ 
dure in A. If two processes call A.a and 
B. b simultaneously, both A and B will be 
locked. The call to B from a will cause the 
first process to block, and the call to A 
from b will cause the second process to 
block, creating a deadlock between the two 
processes. The HM 2 p multiprocessor 
solves this problem by releasing all nested 
monitors when a process becomes 
blocked, and reacquiring them once the 
process is signaled. 

The signal-wait mechanism also 
increases the difficulty of verifying pro¬ 
gram correctness. When a process per¬ 
forms either a signal or a wait operation, 
it relinquishes control of the monitor to 
allow another process to execute. The state 
of the monitor can change drastically 
between the times that a process relin¬ 
quishes and regains control of the moni¬ 
tor. In addition, signals on condition 
variables are not saved; a process will 
always delay regardless of whether there 
are outstanding signals. This can make the 
signal-wait mechanism difficult to use cor¬ 
rectly. Moreover, it is difficult for the 
monitor mechanism to support a very 
small granularity of parallelism efficiently 
because of the delays inherent in the posi¬ 
tive wake-up implementation method. 
Because the monitor mechanism com¬ 
pletely inhibits parallel access to shared 
data, it may be poorly suited for a paral¬ 
lel environment. 

HM J p. The Hierarchical Mul¬ 
timicroprocessor is a tree-structured 
MIMD multiprocessor that uses monitors 
as its underlying synchronization 
method. 10 Its architecture (Figure 6) con¬ 
sists of two similar but disjoint 
hierarchies—the P-hierarchy for process¬ 
ing data and the D-hierarchy for distribut¬ 
ing data. Each node in the P-hierarchy is 
a cluster composed of a set of processors 
connected to a shared cluster memory by 
a bus, switches, DMA interface, and serial 
communication links to its parent and 
child P-processors (which reside in differ¬ 
ent clusters). The serial communication 
links provide access to the shared memory 
of the other clusters. A D-processor is sim¬ 
ply responsible for transferring code and 
data in and out of its associated cluster. As 
in many of the other architectures, the 
cluster provides a way to group closely 
cooperating processes. 

The objective of the HM 2 p is to allow 
maximum concurrency while maintaining 


transparency via a two-level monitor sys¬ 
tem. Monitors, implemented with positive 
wake-up, are used for synchronization, 
interprocess communication, and memory 
allocation. All shared memory is con¬ 
trolled by the monitor mechanism and 
therefore can never be corrupted by con¬ 
current access. 

The HM 2 p has two types of monitors: 
cluster monitors and system monitors. 
Cluster monitors control data shared by 
processors in the same cluster; system 
monitors control data shared among 
clusters. When a monitor procedure is 
called, either a cluster monitor or!a sys¬ 
tem monitor is invoked to perform syn¬ 
chronization and interprocess communi¬ 
cation. A cluster kernel handles the cluster 
monitors for all processes residing in that 
cluster; it maintains a “free” flag, a queue 
of processes waiting to enter monitors, and 
queues of processes waiting for conditions 
for each cluster monitor. Mutually exclu¬ 
sive access to the cluster kernel is secured 
by the bus arbiter: the requesting process 
sets a switch status bit asserting cluster 
request-, when the cluster kernel is free, the 
bus arbiter asserts cluster grant and the 
process proceeds. When a process is wait¬ 
ing in a queue, the processor executing that 
process remains idle until it is signaled. 

A system monitor, an extension of a 
cluster monitor, provides transparency 
and ease of use. If two processes executing 
on processors in different clusters wish to 
communicate, they must do so via a system 
monitor. A monitor used by two such 
processors is located in the closest com¬ 
mon ancestor cluster. A process calls a sys¬ 
tem monitor procedure by passing a 
message through the serial links. 

There are several problems with the 
HM 2 p monitor implementation. The first 
is that the number of processors in a clus¬ 
ter is limited by the bandwidth of the clus¬ 
ter bus. It is therefore inevitable that sys¬ 
tem monitors will be used for highly 
parallel programs. Clusters near the root 
of the tree may become bottlenecks in the 
presence of very active system monitors. 
Parallelism is limited because all shared 
memory, including read-only variables, is 
controlled by monitors and must be 
accessed sequentially. 

Implementations based 
on message passing 

Message passing is a somewhat differ¬ 
ent approach to synchronization. In mes- 
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Figure 6. The HM 2 p system and cluster organizations. 10 


sage passing, all interprocess communi¬ 
cation must take place through the explicit 
transmission of values between two or 
more processes; instead of reading and 
writing shared variables, processes send 
and receive messages. Traditionally, mes¬ 
sage passing has been considered only in 
the domain of distributed systems, such as 
those constructed from the Transputer, in 
which message passing is the sole means of 
interprocess communication. Today, 
however, several multiprocessor systems 
combine message passing with shared 
memory. Some systems are constructed in 
two levels: the first level based on commu¬ 
nication via shared memory, the second 
level based on message passing. Others, 
such as the HEP and the BBN Butterfly, 
use a simplified form of message passing 
to synchronize access to shared memory. 

The implementation of send and receive 
has two primary parameters: how source 
and destination processes are named and 
how communication is synchronized. 
There are three possible methods for 
specifying source and destination designa¬ 
tors (also known as channels of commu¬ 
nication). The simplest method is direct 
naming, in which process names serve as 
source and destination designators. Some 
problems, such as the pipeline paradigm 
(which consists of n processes that com¬ 


municate by the ;th process receiving mes¬ 
sages from the i - 1th and sending to the 
/+lth), are particularly well suited for 
direct naming. Others, such as the cli¬ 
ent/server problem (which consists of mul¬ 
tiple clients and servers, with each server 
servicing any client), are less well suited 
because direct naming does not allow a 
process to receive messages from an arbi¬ 
trary process except through the polling of 
all possible senders. The Transputer uses 
direct naming of both sender and receiver 
because of its direct correspondence with 
point-to-point communication links. 

A more general approach is global nam¬ 
ing, or mailboxes. Instead of a process 
name, a mailbox is specified as the source 
or destination of a message. Any process 
associated with a mailbox can send to or 
receive from it. However, the cost for all 
the members of a mailbox to maintain its 
current status may be quite high. The HEP 
implements global naming by using busy 
waiting to detect that a send or receive 
operation has occurred. 

The third approach, ports, combines 
direct and global naming. Any process can 
send messages to a port, but only one pro¬ 
cess can receive data from it. Ports provide 
the “anonymous” naming available via 
mailboxes without the additional over¬ 
head. The event mechanism of the BBN 


Butterfly uses ports. 

The second primary parameter is 
whether message passing is synchronous or 
asynchronous. A statement is asyn¬ 
chronous if its execution never delays the 
invoker. This implies unbounded buffer 
space; in practice, a bounded number of 
buffers is used and a sender will fail if all 
buffers are currently full. Because the 
sender never has to wait, a higher degree 
of parallelism can be attained with asyn¬ 
chronous message passing. The drawbacks 
are that additional memory is required for 
buffering messages and that the informa¬ 
tion a process receives may be out of date. 
Synchronous message passing uses no 
buffers, so both senders and receivers can 
block. A message exchange always 
represents a synchronization point; the 
sender knows something about the 
receiver’s state, and the receiver always 
receives up-to-date state information. The 
Transputer uses synchronous message 
passing to eliminate the complexity of 
buffer management. 

Another mode of interaction is Dijk- 
stra’s guarded commands." The guard 
consists of a Boolean expression followed 
by a message-passing statement. The 
guard succeeds if the Boolean expression 
evaluates to true and the message-passing 
statement will not cause a delay; it fails if 
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Table 2. A comparison of message-passing-based systems. 


Architecture 

Synchronous 

Naming 

Receive 

Send 

Message Size Buffers 

HEP 

No 

Mailboxes 

Blocking 

Blocking 

1 word 1 

Butterfly 

No 

Ports 

Blocking and nonblocking 

Blocking and select guard 

1 word 1 

Transputer 

Yes 

Direct 

Blocking 

Blocking and select guard 

Not fixed 0 


the Boolean is false. The guard is tem¬ 
porarily suspended if it neither succeeded 
nor failed. The selective guard statement 
consists of a set of guards, each associated 
with a segment of code. When a selective 
guard is evaluated, an arbitrary successful 
guard is selected to be executed; if all the 
guards fail, then the command aborts. 
Otherwise the process suspends until one 
of the two prior conditions occurs. The 
implementation of guards, especially if 
both send and receive can appear within 
them, may be fairly expensive and prone 
to deadlock. Some systems, such as the 
BBN Butterfly, minimize the expense by 
allowing only receive operations to appear 
in a guard. 

Like semaphores, message passing is 
difficult to use correctly because send and 
receive operations are scattered through¬ 
out the program. In general, there is no 
simple mechanism, such as the precondi¬ 
tions and postconditions used with moni¬ 
tors, to formally prove that message¬ 
passing programs are correct. In syn¬ 
chronous message passing, processes can 
deadlock by blocking on messages from 
one another. 

Table 2 summarizes the differences 
among the three message-passing 
implementations described in the follow¬ 
ing paragraphs. 

HEP. The HEP machine, developed by 
Denelcor, is a shared-memory multipro¬ 
cessor. 12 To exploit the very fine-grained 
parallelism resident in large scientific pro¬ 
grams, its designers introduced two fea¬ 
tures: a pipelined processor and a 
one-word message-passing mechanism. A 
HEP multiprocessor consists of 1 to 16 
processors and up to 128 memory units 
connected by a packet-switched network. 
Each processor consists of an execution 
pipeline, a process queue, and a memory 
reference pipeline called the scheduler 
function unit (Figure 7). The SFU, con¬ 
nected to memory by a message-switched 
interconnection network, is used in mem¬ 
ory access and synchronization. Indepen¬ 
dent instructions flow through the execu¬ 


tion pipeline; the delay through the pipe¬ 
line masks the latency of the 
interconnection network. 

Scientific programs achieve high degrees 
of parallelism by partitioning the data 
among concurrent processes and com¬ 
municating partial results (for example, 
assigning each process one entry to com¬ 
pute in a matrix multiplication). The 
HEP’s one-word message-passing scheme 
was designed to accommodate these 
algorithms, which require intensive syn¬ 
chronization and communication. A 
full/empty state bit, associated with each 
memory location and register, is used for 
synchronization. When a process per¬ 
forms a write, it must wait until the mem¬ 
ory location’s state is empty; after the 
location is written, the state bit is set to 
full. These actions are performed atomi¬ 
cally. The converse logic is used for read¬ 
ing. Hence, each variable can be viewed as 
a one-buffer mailbox that every process 
can send to and receive from. 

The SFU is responsible for reissuing 
requests for the unfulfilled memory refer¬ 
ences, thereby decreasing the load on the 
execution pipeline. Unsuccessful attempts 
are returned from the network and the 
request is reinserted in the SFU queue to 
be retried later. Latency for resuming exe¬ 
cution of a process is very low; once the bit 
test is successful, the associated instruction 
is immediately added to the execution 
pipeline. 

A Fortran compiler was extended to 
support full/empty state bits. When a var¬ 
iable declared asynchronous appears on 
the right-hand side of an assignment state¬ 
ment, “wait for full and set empty” 
semantics apply. When it appears on the 
left-hand side of an assignment statement, 
“wait for empty and set full” semantics 
apply. This guarantees that asynchronous 
variables are used correctly. 

The HEP’s hardware-based message¬ 
passing mechanism provides very low 
delay, data-dependent synchronization. 
But the SFU uses network bandwidth in 
busy waiting, and only livelock freedom 
can be guaranteed. Full/empty bits can be 


used to implement weak semaphores: the 
full and empty states correspond to the 
semaphore’s being closed and open respec¬ 
tively; read instructions are P operations, 
and write instructions are V operations. 
Although the extension from one-word 
messages to other types of synchronization 
is generally fairly obvious, the implemen¬ 
tations can be very expensive. 

BBN Butterfly. The Bolt Beranek and 
Newman Butterfly is a tightly coupled, 
shared-memory, network-based multipro¬ 
cessor with 1 to 256 processor nodes con¬ 
nected by a high-speed switching 
network. 13 Each processor node consists 
of a microprocessor, memory, a coproces¬ 
sor known as the processor node controller 
(PNC), and anetwork interface. All mem¬ 
ory is local to some processor node; how¬ 
ever, a process can access the memory 
associated with any node. The network is 
composed of a set of 4 x 4 switching nodes 
with a topology similar to the Fast Fourier 
Transform Butterfly. 

The PNC controls message traffic 
through the network. It initiates transmis¬ 
sion of all messages over the switch and 
processes all messages received at its 
processor node. It also performs the 
virtual-to-physical address mappings for 
local memory access. Hence, it is involved 
in every reference to local memory by both 
local and remote processors and can eas¬ 
ily guarantee atomicity for local memory. 
It provides efficient implementations in 
microcode of a collection of operations for 
parallel processing. These operations 
include queue management, an event 
mechanism, a scheduler that uses knowl¬ 
edge about pending queue and event oper¬ 
ations, and a set of atomic memory 
operations, which can be used to imple¬ 
ment simple locks and interprocess com¬ 
munication facilities. 

The event mechanism controls process 
execution and interprocess communica¬ 
tion through wait (receive) and post (send) 
operations. The event mechanism can be 
viewed as a one-word message-passing 
scheme similar to that of the HEP; each 
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Figure 7. The principal pipelines of a HEP processing element module. 


event descriptor, which is a 32-bit event f 
data field, is a port that one process can L 
receive from and all processes can send to. 

The PNCs are responsible for delivering 
the event to the correct processor node and 
the correct process on that node. Because 
the event descriptor contains enough room 
for receiving exactly one event, one of two 
different actions occurs when a process 
sends to an event descriptor that already 
has an outstanding event. If the event 
descriptor was defined to allow multiple 
outstanding events, it records the data of 
the first event and a count of the number 
of subsequent events. If it does not allow 
multiple events, an error is returned to the 
sending process. Similarly, there are two 
ways to receive events: either nonblocking 
or blocking on a list of event descriptors 
and waking when the first event is sent. 

The second synchronization method 
provided by the PNCs is a set of queue 
primitives. These queues can be used for 
explicitly passing data between processes 
or as the basis of a semaphore or monitor 
mechanism. They can also be used in con¬ 
junction with an event descriptor to cre¬ 
ate a mailbox for a more flexible 
message-passing system than that 
provided by the event mechanism. 

The PNC also provides a process 
scheduler. Close communication between 
synchronization and process scheduling 
allows for very efficient blocking and sig¬ 
naling. If a process blocks on either a send 
or a receive, the PNC scheduler can 
immediately allow another process to run. 

The use of positive wake-up guarantees 
FIFO fairness. Because the scheduler is 
integrated with the message-passing facil¬ 
ity, it could be used to detect or prevent 
deadlock. 

Transputer. The Transputer and the 
Occam programming language are based 
on ideas put forth by Hoare in his descrip¬ 
tion of the Communicating Sequential 
Processes (CSP) programming lan¬ 
guage. 14,15 In the Occam environment 
each program consists of a set of loosely 
coupled processes that execute concur¬ 
rently, sending messages among them¬ 
selves via one-way data paths, called 
channels. The Transputer, a VLSI compo¬ 
nent developed by Inmos, was designed to 
support Occam programs efficiently. 
Thus, support for message passing is an 
integral part of the Transputer archi¬ 
tecture. 

The Transputer (which roughly cor¬ 
responds to a processor node in the BBN 
Butterfly) consists of a processor, mem¬ 


ory, and four point-to-point communica¬ 
tion links to other Transputers. A 
Transputer can address only Transputers 
to which it is directly connected; access to 
other Transputers must be provided by 
higher-level networking software. Multi¬ 
ple Transputers can be arranged in a net¬ 
work with programmable intercon¬ 
nections to create a general-purpose multi¬ 
processor. 

The synchronization mechanism sup¬ 
ported by the Transputer is precisely the 
message-passing protocol defined in the 
Occam programming model, in which 
concurrent processes communicate 
through direct-named, one-way channels. 
There are three Occam primitives: 

assignment: variable : = expression 
send: channel! expression 

receive: channel ? expression 

In addition to these primitives, Occam 
has flow control directives that create par¬ 
allel flows of control, loops, and alterna¬ 
tives (a selective guard). Occam message 
passing is synchronous, with no message 


buffers; both a sender and a receiver can 
block when performing a message-passing 
operation. The alternative statement 
allows a process to wait for a message on 
any of a number of channels. The Occam 
programming model can be used either to 
implement concurrent applications 
directly or as the basis for implementing 
other concurrent programming languages. 

This model is supported directly by the 
Transputer hardware. Channels between 
processes on different processors, called 
external channels, are implemented 
directly with the inter-Transputer links. 
Each link represents two unidirectional 
channels. Channels between processes on 
the same Transputer, internal channels, 
are also supported transparently. Two 
instructions, input message and output 
message, are provided for message passing 
on both internal and external channels. 
Because message passing is synchronous, 
there is no need for internal buffering. 
When both ends of the channel are ready, 
the message is transferred byte by byte 
from the sender’s address space to the 
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receiver’s. 

The Transputer uses direct naming of 
both senders and receivers. Therefore, 
multiple processes never block on the same 
channel, and fairness is not an issue. The 
limitation that a sending process will vir¬ 
tually always block may reduce the possi¬ 
ble parallelism. However, this allows for 
an efficient hardware implementation, 
which minimizes copying of data and 
buffer space. Like the Butterfly, the 
Transputer provides a process scheduler. 
This allows for close communication 
between synchronization and process 
scheduling and can simplify the implemen¬ 
tation of algorithms for detecting or 
preventing deadlock. The design of Occam 
followed the principles of simplicity and 
formality to facilitate proofs of correct¬ 
ness. Thus, Occam can use the axiomatic 
proof techniques developed for CSP. 

I n the realm of parallel processing, 
synchronization is a necessary evil. 
Synchronization causes computation 
overhead, may limit concurrency more 
than is required by the program semantics, 
and increases the complexity of program 
development. Several multiprocessors 
have attempted to minimize these prob¬ 
lems by incorporating support for a syn¬ 
chronization method as a fundamental 
part of their architecture. The Cedar and 
the NYU Ultracomputer provide a set of 
multiple-operation memory access instruc¬ 
tions, which can be used to implement 
weak semaphores. One of the primary 
strengths of these operations, however, is 
that they allow the development of many 
parallel algorithms that are critical- 
section-free. The Sequent Balance/21000 
also supports semaphores; it uses a sepa¬ 
rate network for busy waiting, thereby 
eliminating the network contention pres¬ 
ent on the Ultracomputer and the Cedar. 
Unfortunately, these three solutions suf¬ 
fer from similar problems: minimal fair¬ 
ness guarantees, difficulty of programming 
correctly, and poor utilization of the 
processor. The HM 2 p uses a higher-level 
form of synchronization—monitors— 
which greatly simplifies writing correct 
programs and provides FIFO fairness. 
However, because monitors completely 
inhibit parallel access to shared data—a 
problem compounded on the HM 2 p 
because all its shared memory is controlled 
by monitors—they may be ill suited for a 
truly parallel environment. 

Different varieties of message passing 
have been adopted by several machines. 
The HEP supports a one-word message¬ 


passing scheme as a fundamental aspect of 
its design. The BBN Butterfly uses an intel¬ 
ligent controller, which provides event- 
based synchronization in addition to other 
parallel-processing support. The Trans¬ 
puter is the machine most strongly 
influenced by synchronization; it was 
designed specifically to implement a 
message-passing-based programming lan¬ 
guage, Occam, and hence provides full 
support for synchronous, direct-named 
message passing. 

Ideally, a synchronization method 
would unify parallel programming in 
much the same way that structured forms 
of control have created a uniform style in 
serial programming. However, the choice 
of method is strongly tied to the underly¬ 
ing support mechanisms. For example, if 
the underlying synchronization mecha¬ 
nism works closely with the process 
scheduler, the response time for positive 
wake-up is decreased, and deadlock detec¬ 
tion and prevention are much simpler. 
Although all the synchronization methods 
described here are sufficient to implement 
parallel programs, with so little experience 
in the development of parallel programs, 
we have not yet reached a consensus as to 
which approach is the most fruitful. □ 
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Anne Dinning is working on her PhD in computer science at the Courant 
Institute of Mathematical Sciences at New York University under an IBM 
graduate fellowship. Her research interests include multiprocessor pro¬ 
gramming environments and parallel-program monitoring and analysis. 

Dinning received her BS in computer science from the University of 
Washington in 1984 and her MS in computer science from the Courant 
Institute in 1987. She is a member of the IEEE Computer Society. 


Dinning’s address is Courant Institute of Mathematical Sciences, New 
York University, 251 Mercer St., New York, NY 10012. 


At GTE’s Computer and Intelligent Systems 
Laboratory, we are creating opportunities to 
apply new ideas to research and development 
projects for improved information and telecom¬ 
munication systems. By expanding our scope 
and responsibility, we can better support GTE’s 
telecommunications businesses. And our ac¬ 
tivities create challenges for individuals at the 
MS/PhD level in Computer Science. Join us as 
we continue to make history in telecommunica¬ 
tions technology. 

Our present areas of interest include: 

Distributed Operating 
Systems 

We are currently growing a group that is conduct¬ 
ing research in distributed operating systems and 
distributed transaction systems. These systems 
will unify a network of cooperating autonomous, 
heterogeneous processors and replicated data¬ 
bases. Issues concern not only the tradeoffs between 
network and distributed operating systems, but 
the interoperability of software components imple¬ 
mented on a mix of platforms and languages; included 
are such topics as transport, access, application, 
distributed control and control migration. Research 
is conducted using synthesis and prototyping with 
emphasis on architectural and applicability issues. 
We are looking for individuals at all levels of ex¬ 
perience, however, we require a PhD in Computer 
Science along with a familiarity with the various 
current approaches to the design of distributed 
systems. Significant experience with at least one 
such system is highly desirable. 

Intelligent Database 
Systems 

Our Distributed Object Management (DOM) pro¬ 
ject is conducting research into interconnectivity 
and intelligent interoperability among heterogeneous 
computer systems. We require PhD-level re¬ 
searchers at all levels with a minimum of 2 years’ 
experience in databases, operating systems, 
distributed systems or artificial intelligence. 

Software Reusability 

Topics of interest in the area of software 
reusability include domain analysis, object-oriented 
development, reuse centered software pro¬ 
cesses, tools support for reusability and software 
classification. This area requires an MS/PhD in 
Computer Science and a minimum of 2 years’ 
experience in at least one of the above areas. 

GTE Laboratories offers attractive facili¬ 
ties located in a quiet, wooded setting just 
outside of Boston, as well as a highly 
competitive salary and benefits package. 
We invite you to send a resume to 
Vanessa Stem, GTE Laboratories, Inc., 
Box IEEEC7, 40 Sylvan Road, Waltham, 
MA 02254. An equal opportunity 
employer, M/F/H/V. 

Laboratories 
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You are invited to attend: ODPSLA ’ 69 


Fourth Annual Conference on 

Object Oriented Programming Systems, Languages, and Applications 

October 2-6,1989 at the Hyatt Regency, New Orleans, Louisiana 

ODPSLA ' 89 is the fourth annual conference bringing together users, researchers, and implementors of 
object oriented systems. We are presenting a program of tutorials, workshops, panels discussions as well 
as exhibits and demonstrations. The technical program is a selection of some of the best current work on 
object oriented technology. This conference is a forum for sharing experience and knowledge among 
both experts and newcomers to this rapidly growing field. Space is limited, so register early. 

Sponsored by the Association for Computing Machinery's Special Interest Group on Programming Languages (ACM/S1GPLAN) ACM® 


Monday, 2 October 1989 

Tutorials; morning session 

1 The Concepts of Object-Oriented Program¬ 
ming; David Smith, IBM (Full day) 

2 MacApp™; An Object-Oriented User 
Interface Toolkit; Kurt Schmucker, Apple 
Computer, Inc. (Full day) 

3 Introduction to C++; Robert Murray, AT&T 
Bell Laboratories (Full day) 

4 Engineering Object-Oriented, Interactive 
Software; Charles Hughes, University of 
Central Florida and Mahesh Dodani; 
University of Iowa (Full day) 

5 Object-Oriented Concurrent Systems; Gul 
Agha; Yale University and Peter Wegner; 
Brown University (Full day) 

6 Introduction to Object-Oriented Database 
Management Systems; Concepts and 
Applications; Jeffrey Sutherland, Graphael, 
Inc. (1/2 day) 

1:30 pm - 4:30 pm 

Tutorials; afternoon session 

7 Object-Oriented Database Concepts: A 
ResearchPerspective; Stan B. Zdonik, Brown 
University (1/2 day) 

6:00 pm - 8:00 pm 
Tutorial reception 


Tuesday, 3 October 1989 

9:00 am -12:00 noon 

Tutorials; morning session 

8 Smalltalk, MacApp™, and NextStep™: 

A Comparison of Three Object-Oriented 
Development Systems; David Wilson, 
Personal Concepts and Neil Goldstein, 
Neil Goldstein Design, Inc. 

9 Object-Oriented Analysis; Peter Coad, 
Object International (Full day) 

10 The BETA Programming Language; Ole 
Lehrmann Madsen, Aarhus University; 
Birger Moller-Pedersen, Norwegian 
Computing Center; and Kristen Nygaard, 
University of Oslo (Full day) 


Technical Program 


11 Advanced Programming Concepts in C++; 
Lewis Pinson and Richard Wiener, 
University of Colorado (Full day) 

12 Object-Oriented Design; Grady Booch, 
Rational (Full day) 

13 ET++: A Portable C++ Class Library for a 
Unix Environment; Rudolf Marty, Erich 
Gamma, and Andre Weinand, University of 
Zurich (1/2 day) 

10:00 am 

Exhibits open 

1:30 pm - 4:30 pm 

Tutorials; afternoon session 

14 Rapid Prototyping; Sam Adams, Knowl¬ 
edge Systems Corporation (1/2 day) 

15 Managing Object-Oriented Engineering; 
Dave Thomas, Carleton University and Ivar 
Jacobson, Objective Systems AB Sweden 
(1/2 day) 

6:00 pm -10:00 pm 

Welcoming Reception 


Thursday, 5 October 1989 

8:30 am -10:00 am 

Session 5A: Agents 

Session 5B: Scientific Computing 


10:00 pm 

Exhibits open 


Session 6A: Objects in Business 
Session 6B: Panel: Inheritance 

1:30 pm - 3:00 pm 

Session 7A: CLOS 
Session 7B: Panel: ADA 

3:30 pm - 5:00 pm 

Session 8A: Implementation 2 
Session 8B: Modeling 

6:30 pm - 8:00 pm 

Pre-banquet Reception 

8:00 pm -10:00 pm 
Banquet 


Wednesday, 4 October 1989 

Session 1: Keynote Address 


10:30 am -12:00 noon 

Session 2A: Teaching 
Session 2B: Implementation 1 


1:30 pm - 3:00 pm 

Session 3A: Software Engineering 
Session 3B: Panel: Transactions 


3:30 pm - 5:00 pm 

Session 4A: Concurrency 

Session 4B: Panel: The Future of OOP 


Friday, 6 October 1989 

8:30 am -10:00 am 

Session 9A: Reflection 
Session 9B:Varia 

1:30 pm - 3:00 pm 

Session 10A: Delegation/Constraints 
Session 10B: Panel: Database Architectures 

1:30 pm - 3:00 pm 

Session 11A: Inheritance 

Session 11B: Panel: Software Revolution 

3:30 pm - 5:00 pm 

Session 12A: Theory 
Session 12B: Panel: Languages 


5:00 pm - 7:00 pm 
Exhibit Reception 


Exhibits 

Both software and hardware vendors of object oriented systems will present exhibits 
in the OOPSLA '89 Exhibit Hall. Exhibiting vendors will also be making multiple 
presentations of their products in exhibitor presentation rooms. Exhibit hours are 
10-6 on Tuesday, 4 October; 10-7 on Wednesday, 5 October; and 10-6 on Thursday, 6 
October. 

For further information on exhibits contact Timlynn Babitsky or Jim Salmons, JFS 
Consulting, 345 West First Street, Suite #56; Tustin, CA 92680, (714) 731-9022. 


For a copy of the Advance Program, 

please send a written request to: 

OOPSLA '89 

c/o Jeff McKenna 

The McKenna Consulting Group 

8825 SW Umatilla Street 

Tualatin, OR 97062 

-or FAX to (503) 692-3194 









Hotel Reservation Form forCZDPSLA ’ 89 

Mail this form to: 

Hyatt Regency New Orleans 
Reservations Center 
Poydras at Loyola Avenue 
New Orleans, Louisiana 70140 
Or Call: (504) 561-1234 

We would like to welcome you in advance as a participant at 
OOPSLA '89. To assure a confirmed room, this form must be 
received by the hotel no later than 25 August 1989. OOPSLA 
has traditionally been sold out, so make your reservations 

THIS IS A RESERVATION REQUEST AND MUST BE 
ACCOMPANIED BY A ONE NIGHT ROOM DEPOSIT OR 
CREDIT CARD GUARANTEE. 

_ Credit Card Type (circle): AX DC CB VISA MC 

Expiration Date_ 

Card #_ 

_ Deposit (one night's rate plus 10% plus $2.00 ) 


Daily Room Rates 

(Applicable 3 days before/after conference dates): 

_Single $100.00 _ Double $110.00 

All rates are subject to a 10% tax and $2.00/night room tax. 

A written confirmation will be mailed to your address. 


Affiliation_ 

Sharing with 
Address _ 


City_State_ZIP _ 

Country ___ ^ t ■ - _>_ 

Arrival Date_Time_Departure Date_ 

Check in time is 3:00 pm; check out time is 12:00 noon. 


GDPS LA ’ 69 
Registration Form 


Affiliation 


Please print or type all information 


Mail Conference Registration To: 

OOPSLA '89 

P.O. Box 1719 

151 N. Maitland Ave. 

Maitland, Florida 32751 


Address_ _ __ 

City_ State_ZIP 

Country_ ■ _ Phone _ 

(Indude country, area, and dty codes as appropriate) 


Conference registration includes: admission to 
technical sessions, exhibits, one (1) banquet 
ticket and one (1) copy of the proceedings. 

Tutorial fee includes: admission to selected 
session, one (1) copy of tutorial notes for that 
session and lunch for the day of the tutorial. 

Payment: Registration forms will be processed 
only if accompanied by full payment in U.S. 
Dollars. Payments can be made by personal or 
company checks, money orders, or cashier's 
checks. Checks or money orders must be 
drawn on a U.S. bank and must have machine- 
readable account numbers. Please make checks 
payable to OOPSLA '89. 

Funds may also be wired to our account 
(#68439973) at The Bank of New York, 1150 
Knollwood Road, White Plains, NY, 10602 
(ABA #021902352,914-592-9432). You must 
send the receipt for the wire transfer with the 
registration form. 

Purchase orders, credit cards, and government 
vouchers cannot be accepted. Registration 
forms and payments submitted separately will 
be returned. No phone registrations accepted. 

Registration confirmation: Every effort will be 
made to notify registrants prior to the 
conference. Please allow three weeks for 
confirmation of your registration after mailing. 

Refund: Refund requests must be by letter and 
postmarked on or before 31 August 1989. All 
refunds will be mailed out four weeks after the 
conference ends. 

Sellout Policy: All registrations will be 
processed on a first-come, first-served basis, 
based on the date of receipt. 


□ Note: The conference attendee list may be 
made available to outside organizations. Check 
here if you DO NOT want your name to appear 
on this list. 


Registration Category: (Check only one) 

□ Member of ACM Member #_ 

□ Full time student ID #_ 

□ Non-member 

Tutorial Selections 

Circle first choice selections: 


Monday, 2 October 1989 
Tutorial # AM PM 



Total Monday units (Maximum of 2) 


Fees (in U.S. Dollars) 

Prices Per Tutorial Unit 

Received on or Received 

before 25 Aug. after 25 Aug. 

ACM Member $105 $130 

Non-member $125 $150 

Student $30 $130 

Tutorial Fee: 

_tutorial units x $_/unit = $_ 

Prices For Conference 

Received on or Received 

before 25 Aug after 25 Aug 

ACM Member $175 $235 

Non-member $215 $275 

Student $60 $60 

Conference Fee: $_ 

Extra Banquet Tickets Fee: 

_extra tickets x $50 = $_ 

Total Payment $_ 


Tuesday, 3 October 1989 




Total Tuesday units (Maximum of 2) 


Total tutorial units (Maximum of 4) 


0 





































C °SS5 NEWS 


Editor: Guylaine M. Pollock, Parallel Computing Science Division 1424, Sandia National Laboratories, PO Box 5800, Albuquerque, NM 87185, 


Board of Governors approves slate of candidates for this fall’s elections 


The IEEE Computer Society Board 
of Governors has approved the slate of 
candidates for president-elect, first vice 
president, second vice president, and 
seven board posts that will be filled by 
membership vote this fall. The board 
took action on the slate when it met in 
Pittsburgh May 19 during the 11th 
International Conference on Software 
Engineering. 

Those elected, including the seven 
candidates garnering the greatest num¬ 
ber of votes among the 16 Board of 
Governors nominees, will begin their 


terms January 1, 1990. 

The candidates are as follows: 

1990 president-elect (1991 president, 
1992 past president) 

(One elected) 

Duncan H. Lawrie 
Joseph E. Urban 

1990 first vice president 

(One elected for one year) 

Barry W. Johnson 
Laurel V. Kaleda 


1990 second vice president 

(One elected for one year) 
Paul L. Borrill 
Bill D. Carroll 


1990-92 Board of Governors 

(Seven elected for three years) 
Jon T. Butler 
Alicja I. Ellis 
Gerald L. Engel 
Tadao Ichikawa 
Michel Israel 
David Pessel 


Board votes $3 membership rate hike to boost services, offset costs 

Sallie V. Sheppard, Vice President, Publications 


The IEEE Computer Society Board 
of Governors approved a $3-a-year 
membership rate increase for 1990 
when it met May 17 in Pittsburgh dur¬ 
ing the International Conference on 
Software Engineering. 

The increase, to $18 from $15 a 
year, will enable the society to offset 
rising operational expenses and 
expand membership services, includ¬ 
ing publishing additional pages in 
Computer. 

The Computer Society member¬ 
ship fee must be set at the board’s 
yearly May meeting to meet IEEE 
deadlines. 

Preliminary budget. Development 
of the preliminary Computer Society 
budget for 1990 was a major topic of 
discussion at the board meeting as 
well as at many society board and 
committee meetings held earlier in 
the week. Although the 1990 budget 
will not be adopted until the board’s 
meeting in November, a preliminary 
budget must be developed in May to 
set page budgets and subscription 


rates for publications and to modify 
society membership dues. 

Treasurer Charles Silio presented a 
draft budget at the board caucus 
May 15 that projected a $1.3-million 
deficit for 1990 without increases in 
publication pricing and member 
dues. The reasons for the projected 
deficit included increased costs for 
publication preparation and mailing, 
proposed increased services for 
members, and increased staff costs. 

For the last several years, the soci¬ 
ety has adopted deficit budgets that 
nearly broke even or had slight sur¬ 
pluses. For example, the audit of the 
1988 budget completed in April 
showed a $26,200 surplus, although 
the adopted budget had projected a 
$509,200 deficit. The difference 
between the projected and actual 
results was primarily due to staff sal¬ 
ary savings on vacant positions and 
higher incomes than projected from 
increased conference attendance, 
press sales, and publication sub¬ 
scriptions. 

However, Silio warned that the 


projected 1990 deficit of $1.3 million 
would result in a real deficit. He 
therefore proposed a budget that 
projected a smaller deficit. His plan 
was discussed in numerous meet¬ 
ings during the week. The discus¬ 
sions culminated in the adoption of 
the new page budgets and subscrip¬ 
tion rates and the $3 dues increase. 

Based on these decisions, the 
board directed Silio to work in con¬ 
junction with President Ken Ander¬ 
son, President-elect Helen Wood, 
and Executive Director Michael 
Elliott to develop a balanced budget 
for presentation at the board’s 
November meeting. 

Page budgets, subscription rates. 

To better serve the society’s mem¬ 
bers, page budget increases were 
approved for three of its magazines: 
Computer, 48 pages; IEEE Software, 
48 pages; and IEEE Expert, 210 
pages. IEEE Expert, until now a quar¬ 
terly, will be published bimonthly 
beginning in 1990. 

The page increases will enable the 
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Ralph J. Preiss 
Sallie V. Sheppard 
Bruce D. Shriver 
Charles B. Silio 
Harold S. Stone 
Jacques Tiberghien 
Wing N. Toy 

Anneliese von Mayrhauser 
Ronald D. Williams 
Marshall C. Yovits 

Additional nominees can be included 
on the ballot by membership petition 
(see Computer, February 1989, p. 81, 
for a complete list of Computer Society 
requirements for petition candidates). 

Petition candidates must submit their 
petition signatures (250 voting members 
for officer nominees and 50 voting 
members for Board of Governors 
nominees) and their biographical data, 
photographs, and position statements 
to the Computer Society secretary at the 
following address on or before July 31, 
1989: 

Michael Evangelist 
MCC, Kaleido II Bldg. 

9390 Research Blvd. 

Austin, TX 78759 


Candidates’ statements and 
biographical data will be published in 
the September 1989 issue of Computer 
and will be included in the September 1, 
1989, IEEE ballot mailing. Length limi¬ 
tations for these materials are as 
follows: 

Candidates ’ statements 

President-elect 350 words 

Vice president 250 words 

Board of Governors 150 words 

Biographical data 

All candidates 200 words 

Biographical sketches should cover 
the following topics in the sequence 
listed: 

• Computer Society activities 

• other professional activities 

• current employment, professional 
experience, and accomplishments 

• degree(s) and majors(s) 

• awards and honors 

Nominees should also submit black- 
and-white passport-type photographs of 
themselves for publication along with 
their statements and biographies. 


magazines to expand the number of 
technical papers published and 
increase the amount of departmental 
coverage included in each issue. 

Computer is distributed to all 
members as a benefit of their mem¬ 
bership without additional cost. 
However, to further offset the 
increased costs of producing the 
additional pages in the other maga¬ 
zines, the board adopted a $2 
increase in the member subscription 
rate for IEEE Software and a $4 
increase in the member subscription 
rate for IEEE Expert. Rates for other 
categories of subscribers were 
adjusted accordingly. 

The three other Computer Society 
magazines, IEEE Micro, IEEE Com¬ 
puter Graphics and Applications, and 
IEEE Design and Test, will retain the 
same number of pages while increas¬ 
ing their member subscription rates 
by $1 to offset increased costs. 

Three IEEE transactions will be 
decreased in editorial pages during 
1990. IEEE Transactions on Com¬ 
puters and IEEE Transactions on 


Software Engineering will be reduced 
by 100 pages each, and IEEE Trans¬ 
actions on Pattern Analysis and 
Machine Intelligence will be reduced 
by 50 pages. All three of the transac¬ 
tions had received large page-budget 
increases in 1989 to help reduce sub¬ 
stantial article backlogs. To offset 
increased costs, no decreases in 
subscription rates were adopted. 

The two new transactions, IEEE 
Transactions on Knowledge and Data 
Engineering and IEEE Transactions 
on Parallel and Distributed Systems, 
will continue at their initially pro¬ 
posed page budgets and subscrip¬ 
tion rates. 

The board recommended three 
editors-in-chief for appointment by 
the president. They are Balakrishnan 
Chandrasekaran of IEEE Expert, 
Manuel A. d’Abreu of IEEE Design 
and Test, and Victor Basili of IEEE 
Transactions on Software Engineer¬ 
ing . This will be Basili's second 
term. All three terms will be for two 
years and will begin in January 1990. 


Database Engineering 
and Simulation TCs 
to start collecting dues 
to help fund activities 

Laurel V. Kaleda, Second Vice 

President, Technical Activities 

The Technical Committee on Data¬ 
base Engineering and the Technical 
Committee on Simulation have become 
the first IEEE Computer Society TCs to 
adopt dues-collecting programs to help 
defray the cost of funding their 
programs. 

The two TCs proposed charging dues 
for membership when the society’s 
Technical Activities Board (TAB) met 
in Pittsburgh in May. Each TC will 
charge fees of $15 for society members 
and $25 for nonmembers. 

An article concerning TC dues 
appeared on p. 76 of the March 1989 
issue of Computer. At the time, TAB 
had just finished its winter meeting, 
during which the general process for 
establishing TC dues was developed. 

TCs are the groups that sponsor most 
of the activities of the society. They 
receive some society funds to pay for 
their activities, but depend on income 
from certain activities—chiefly confer¬ 
ences and workshops—to fund most of 
their programs. As they develop more 
activities that are not self-supporting, 
they must work to find alternative 
financing. This is essentially the basis of 
the TC dues effort: to allow a TC to 
establish alternative financing for 
extending its member service programs. 

The two TCs that indicated they wish 
to charge dues reflect the funding prob¬ 
lem. The TC for Database Engineering 
has a very popular newsletter, but it had 
to develop substantial funding to con¬ 
tinue to distribute the newsletter free of 
charge. Recent funding had come from 
a corporate grant or from an overrun 
(“deficit”) budget. Neither of these 
were sources for reliable, long-term 
funds. 

Rather than charge all society mem¬ 
bers additional dues to support such 
focused efforts, it seemed to make more 
sense to charge a modest amount to 
those members who benefit directly 
from the activity to directly support 
that activity. The same reasoning was 
applied to the current activities of the 
TC for Simulation. Its joint newsletter 
with its Association for Computing 
Machinery counterpart is a solid and 
reasonable member service, but it is not 
fundable from the TC’s current budget. 
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Beginning this month, the current 
members of the two TCs will receive a 
request for a membership fee. A clear 
description of the services to be deliv¬ 
ered for the stated fee will accompany 
the request. The income from these fees 
will be used to directly fund activity 
programs and allow the two TCs to 
plan the new, enhanced, or modified 
activities that best match the wishes of 
their members. 


Very few members provided com¬ 
ments based on the March article about 
the prospect of charging dues to sup¬ 
port selected TCs. Most of the com¬ 
ments were evenly divided as to whether 
the basic idea was good or bad. We 
hope that, by having two solid offerings 
to start the TC dues program, we can 
demonstrate the value of establishing 
more direct and regular funding for TC 
programs. 


In the case of these TCs, their current 
members will be able to “vote with their 
pocketbooks” on the value to them of 
the services provided. Both TAB and 
the TCs have tried to ensure that the 
value of the packaged services to be 
provided for the dues is worth more to 
the member than the actual dues being 
charged. In that way, through value 
recognized and delivered, this process 
will be considered successful. 


Computer Society salutes its 100,000th member 
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Yamada, Cooke 
presented Outstanding 
Contribution Certificates 
at ICSE 11 

IEEE Computer Society Board of 
Governors member Akihiko Yamada 
of NEC and Christopher Cooke of 
Martin Marietta Aerospace were 
presented Outstanding Contribution 
Certificates during society award 
ceremonies May 17 in Pittsburgh. 

The event was held during the 11th 
International Conference on Soft¬ 
ware Engineering. 

Yamada was cited for leadership in 
planning and implementing the soci¬ 
ety’s Asian office, and Cooke was 
honored for “work leading to the 
establishment of IEEE Standard 
1063, Software User Documen¬ 
tation.” 

Meritorious Service Certificates 
were announced for Paul Borrill, Tom 
Kurihara, and Peter Ron Prinzivalli, as 
was a Certificate of Appreciation for 
John W. Walz. 

Borrill was cited for “years of dedi¬ 
cated service to the society and its 
standards activities”; Kurihara for 
“outstanding technical contributions 
in international standards develop¬ 
ment”; Prinzivalli for “major efforts 
leading to the establishment and 
enhancement of a financial manage¬ 
ment system for the society’s stan¬ 
dards program”; and Walz for 
“support of the society’s Standards 
Activities Board as secretary." 

James T. (Tom) Cain formally 
accepted the first Computer Society 
Taylor Booth Award, announced at 
Compcon Spring 89 in San Francisco 
(see Computer, January 1989, p. 105, 
and April 1989, pp. 76-77). Cain’s 
father, James, was on hand for the 
Pittsburgh ceremony. 

Harold S. Stone, a member of the 
society’s Board of Governors who 
was a fellow in the National Science 
Foundation’s Graduate Research Fel¬ 
lowship program, was presented a 
society certificate in commemora- 


COMPUTER 



Mark Funkenhauser, a 30-year-old 
Canadian researcher and graduate stu¬ 
dent, has been honored as the 100,000th 
member of the IEEE Computer Society. 

Funkenhauser became the society’s 
100,000th member on December 5, 

1988. To commemorate that milestone, 
the society presented him a plaque May 
17 during its 11th International Confer¬ 
ence on Software Engineering in 
Pittsburgh. 

Funkenhauser is employed by 
Thompson Foss, a Toronto-based com¬ 
puter consulting firm; has done gradu¬ 
ate work in the Department of 
Electrical Engineering Computer Group 
of the University of Toronto; and now 
lives in Kitchener, Ontario. 

In his work for the company, 
Funkenhauser is involved in the univer¬ 
sity’s Computer Systems Research Insti¬ 
tute Trusted Tunis project. Tunis, an 


acronym for Toronto University Sys¬ 
tem, is the university’s adaptation of a 
Unix system. 

His present work on Tunis is totally 
separate from his graduate-degree 
studies. It deals with the security aspects 
of operating systems; specifically, 
designing and integrating confidential¬ 
ity security mechanisms into Trusted 
Tunis that meet Canadian as well as US 
government criteria and standards. 

Funkenhauser said he first learned of 
the Computer Society as a student at 
the university and decided to join the 
society to keep abreast of current com¬ 
puter research and receive its peri¬ 
odicals. 

He did his undergraduate work at the 
University of Western Ontario, where 
he received a BSC degree in computer 
science in 1982. 


Computer Society President Ken Anderson (center) presents plaque to the society’s 
100,000th member, Mark Funkenhauser. Barry Johnson (right), vice president of 
membership and information for the society, introduced Funkenhauser during the 
Pittsburgh awards ceremony. 













NEWS FROM THE COMMITTEE ON PUBLIC POLICY 

Draft 7B: Entity Position Paper on Software Vandalism 


The Institute of Electrical and Elec¬ 
tronics Engineers (IEEE) sustains a 
code of ethics that respects the rights 
and property of others and that fosters 
the safety and well-being of the public 
at large. The creation and dissemination 
of computer viruses for unauthorized 


purposes, a form of software vandal¬ 
ism, violates this code of ethics and is 
therefore labeled as an unethical, 
unprofessional, and criminal act. 

The IEEE Computer Society, the 
largest of 33 technical societies in the 
IEEE, has a membership of more than 


100,000 computer professionals in aca¬ 
demic, industrial, and government posi¬ 
tions worldwide. Our members design, 
build, program, test, and manage the 
computers and computer networks so 
pervasive in today’s culture. Through 
their special roles in the computer 


tion of the program’s 25,000th grant. 
Stone, in turn, described for the 
attendees how the GRF program 
operates and discussed some of its 
successes. The society also 
presented a certificate to NSF repre¬ 
sentative Bruce Barnes in apprecia¬ 
tion of the GRF program. 

Amrit L. Goel received his IEEE fel¬ 
low certificate (see Computer, March 
1989, pp. 74-75). 


Harold Stone (third from left) accepted 
a society certificate recognizing his par¬ 
ticipation in the National Science Foun¬ 
dation Graduate Research Fellowship 
program, and Bruce Barnes (right) of 
the NSF received a certificate stating the 
society’s appreciation of the GRF pro¬ 
gram. Jerry Engel (second from left), 
vice president of education, made the 
presentations. With them are Helen 
Wood, president-elect of the society, 
and Ed Parrish (fourth from left), past 
president. 



Christopher Cooke (second from left) and Akihiko Yamada (third from left) 
received Computer Society Outstanding Contribution Certificates at ceremo¬ 
nies officiated by society President Ken Anderson (left) and Awards Committee 
Chair Marshall Yovits. 



Ken Anderson (right) presented an 
IEEE fellow certificate to Amrit 
Goel. 
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industry, IEEE Computer Society mem¬ 
bers are often involved in the design of 
the critical functions a computer virus 
must exploit in order to sabotage a 
computer system’s operation. 

In recognition of our professional 
responsibilities, this position paper 
serves three functions: 

(1) It examines the problem posed by 
computer viruses. 

(2) It clarifies the relationship of 
computer viruses to professional 
conduct. 

(3) It proposes meaningful practices 
for professional, industrial, educa¬ 
tional, and government organizations to 
adopt. 

The essential principle we must first 
establish is that all rights of property 
and privacy should be extended to the 
ownership of computer systems. This 
encompasses their application, the pro¬ 
grams and data stored and used within 
them, and the communications net¬ 
works that interlink them. 

A computer provides services to its 
users. These services are defined by the 
programs and data available in the com¬ 
puter. Coupled with authorized activi¬ 
ties of authorized users, these 
applications bound a computer system’s 
intended operations. Each computer 
system and all data and programs per¬ 
forming these services have recognized 
owners, lessees, or authorized users. 

When a computer owner is not the 
exclusive user, permission to use or 
access some or all of the available ser¬ 
vices, or to extend specific rights of 
ownership, is granted by the computer 
owner (or his agents) to specific users. 


Definitions 


A “trap door” provides a hidden 
software (or hardware) mechanism 
that permits computer system pro¬ 
tection mechanisms to be circum¬ 
vented. 

A “time bomb” is a trap door that 
is activated by a particular set of cir¬ 
cumstances, usually occurring over 
time. 

A “Trojan Horse” is a program with 
an apparently or actually useful func¬ 
tion, but that also performs an unex¬ 
pected (deleterious) function. 

A “worm” is a program that repli¬ 
cates itself throughout a computer 
system or network through its own 
exclusive efforts. In the process, it 
overlays or erases other programs or 
data, making them useless. 


This statement is a draft prepared 
by the Subcommittee on Computer 
Ethics of the IEEE Computer Society 
Committee on Public Policy and 
approved by the society’s Member¬ 
ship and Information Board March 2, 
1989. It has not been approved by the 
Board of Governors of the IEEE Com¬ 
puter Society and is not an official 
position of the Computer Society. 

Ralph J. Preiss, the acting chair of 
the Committee on Public Policy, 
invites you to send comments about 
the draft to him at 12 Colburn Dr., 
Poughkeepsie, NY 12603; 

Compmail+ r.preiss. 


Usually, a computer system contains 
an access control mechanism to prevent 
unauthorized use. Any deliberate effort 
to thwart a computer’s access control 
mechanism amounts to attempted 
breaking and entering and should be 
treated as such under law. Successful 
penetration of such security features is 
equivalent to trespassing as well as 
breaking and entering. 

The deliberate unauthorized use of 
computer services by any person consti¬ 
tutes theft of service and should be 
treated as such under law. 

Any deliberate unauthorized addi¬ 
tion, deletion, or change to (or intro¬ 
duction of new) programs and/or data 
in a computer system is an act of van¬ 
dalism and should be treated as such 
under law. 

A software vandal uses a program to 
facilitate the wrongdoing. The program 
employs features of a class of programs 


There are two types of computer 
viruses: 

A “computer virus-A” infection 
occurs when a Trojan Horse program 
is allowed to spread to (and is there¬ 
fore said to “infect”) another com¬ 
puter. The virus requires human 
intervention (usually inadvertently) to 
spread to another computer. Trans¬ 
mission may occur by copying the 
Trojan Horse from a computer bulle¬ 
tin board or a “contaminated” remov¬ 
able disk to another computer 
system. 

A “computer virus-B” infection is 
far more insidious. This is a program 
that can modify the executable code 
of another program and add the mali¬ 
cious instructions that now cause 
the other program to become a Trojan 
Horse. The other program is now said 
to be infected. Contamination of 
additional computer systems occurs 
in the computer virus-A manner. 


deliberately designed to bypass or elude 
a computer’s security or integrity. 

These programs are called “trap 
doors,” “timebombs,” “Trojan 
Horses,” “worms,” and “viruses” (see 
the sidebar for definitions). 

Computer professionals performing 
computer virus research are expected to 
follow good laboratory practice; viz., 
they must ensure that the experiment 
does not become contaminated, and 
that the experiment does not con¬ 
taminate or spread to anything outside 
the laboratory environment. 

Deliberate tampering with another’s 
data or programs, however clever the 
method, is unprofessional, unethical, 
irresponsible, and criminal. Often, such 
acts have been rationalized as efforts to 
understand the inner workings of com¬ 
puter systems. However, one must 
recognize the difference between 
penetrating one’s own computer and 
penetrating another computer, or a net¬ 
work that belongs to others. 

In order to address the software van¬ 
dalism problem, the following actions 
are recommended: 

(1) The Board of Governors of the 
IEEE Computer Society should publi¬ 
cize the fact that software vandalism 
constitutes unethical, unprofessional, 
and criminal behavior. 

(2) The academic accrediting agen¬ 
cies, such as the Computing Sciences 
Accreditation Board (CSAB) and the 
Accreditation Board for Engineering 
and Technology (ABET), will be urged 
to ensure that their standards provide 
for appropriate coverage of ethical and 
professional conduct in university com¬ 
puter science and computer engineering 
curricula. 

(3) Employers will be advised to 
emphasize to their current and potential 
employees that they do not condone 
software vandalism. 

(4) Governments will be urged to 
update or enact laws to recognize the 
seriousness of computer crimes. The 
IEEE Computer Society will be pre¬ 
pared to provide expert assistance to 
government bodies, if requested. 

(5) Members of the society will be 
reminded to adhere to the following 
professional obligations: 

• Respect the property and privacy of 
others. 

• Support programs to improve the 
security of computer systems. 

• Notify the owner of a computing 
service in case a weakness in the security 
mechanism or an actual security breech 
is discovered. 

• Support and participate in activities 
geared to educating the public about 
software vandalism and its ramifi¬ 
cations. 
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UPDATE 


Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues to Update Editor, 10662 Los Vaqueros Circle, Los Alamitos, 
CA 90720, or to Bruce Shriver, Editor-in-Chief, Dept, of Decision Sciences, University of Hawaii, 2404 Maile Way, Honolulu, HI 96822. 


Noyce urges stringent action against trade violators 


Until the United States and Japan 
reach a balanced level of trade, Japan¬ 
ese companies should pay graduated 
tariffs for the benefit of American in¬ 
dustry, urged Robert N. Noyce in testi¬ 
mony before the US Trade Representa¬ 
tive’s 301 Committee May 24. 

“Japan’s goal of protecting its home 
market and attempting to monopolize a 
segment of the American market has 
drawn the rightful attention of the US 
government,” said Noyce, who testi¬ 
fied on behalf of SEMI/Sematech, an 
organization of 138 equipment and ma¬ 
terials suppliers to the semiconductor 
industry. Noyce is a director of SEMI/ 
Sematech and president and chief ex¬ 
ecutive officer of Sematech, a consor¬ 
tium of 14 companies seeking US lead¬ 
ership in semiconductor manufacturing. 

Noyce testified that Japan violated 
trade laws by denying American com¬ 
panies access to Japanese markets 
while using predatory pricing to mono¬ 
polize American markets. 

“It should be emphasized that pro¬ 
tectionism, dumping, and monopoliz¬ 
ing are considered sound business 
strategy in Japan; in this country, such 
practices are against the law and vio¬ 
late the American desire for fair and 
honest competition,” he said. 

Noyce called on the committee to hit 
offending Japanese industry with 
graduated tariffs beginning at 6 percent 


and increasing by 2 percent a month 
until US-Japan trade levels balance. 

The approaches Noyce suggested to 
the committee included: 

• requiring Japanese telecommunica¬ 
tions products to carry a label warning 
consumers that “buying this product 
endangers American jobs and the US 
standard of living”; 

• requiring Japanese importers to 
certify that their products do not vio¬ 
late American antidumping, copyright, 
or other intellectual property laws; and 

• using funds from the tariffs to com¬ 
pensate the American telecommunica- 


US universities awarded a record 
20,250 doctorates in science and engi¬ 
neering fields in 1988, according to the 
National Science Foundation’s annual 
Survey of Earned Doctorates. 

Although the number of US citizens 
earning doctorates increased in 1988, 
the record showing was primarily fu¬ 
eled by foreign citizens. In 1988, 

12,850 US citizens received doctoral 
degrees (1971 marked the high point, 
with 15,000 doctorates). 

Doctoral awards in engineering 
showed the most growth, reaching 
4,190 in 1988, a 13 percent increase 


tions industry, to supplement semicon¬ 
ductor and high-definition television 
research, and to pay for increased en¬ 
forcement of existing trade laws. 

“Our actions in this and other trade 
matters should reflect a long-term stra¬ 
tegic approach instead of reacting to 
specific problems as they arise,” 

Noyce said. 

The committee heard testimony re¬ 
garding sanctions proposed by the US 
Trade Representative against Japanese 
products in retaliation for denying U.S. 
companies access to the Japanese tele¬ 
communications market. 


over 1987. Specifically, electrical and 
chemical engineering doctorates 
awarded increased 28 percent and 18 
percent, respectively. 

Foreign citizens accounted for 54 
percent of all engineering doctorates in 
1988. However, for the third year, the 
percentage increase of US citizens ex¬ 
ceeded that of foreign citizens (14 per¬ 
cent and 11 percent, respectively). 

Doctoral awards in the sciences rose 
3 percent to 16,067. Computer science 
doctorates showed a 14 percent increase. 

Foreign citizens earned 26 percent of 
all doctorates in the sciences in 1988. 


Universities award record number of doctorates 


Study: $54,700 mean 
income for IEEE 
members 

The 1988 mean or average pre-tax 
income of nonstudent US IEEE mem¬ 
bers is $54,700, according to the 
IEEE USA Membership Salary and 
Fringe Benefit Survey: 1989. The 
mean is slightly higher — $56,000 
— for those survey respondents 
working full-time in their primary 
area of technical competence. The 


survey was published May 9 by IEEE 
United States Activities in Washing¬ 
ton, DC. 

Median salaries in cities with the 
highest concentration of electrical 
and electronics engineers include San 
Francisco, $59,000; New York, 
$58,000; Washington, DC, $56,100; 
Seattle, $49,600; Chicago, $47,000; 
and Dallas-Ft. Worth, $46,500. 

Respondents with doctorates 
earned the highest median incomes 
($62,400), while those with bache¬ 
lors of science degrees in electrical 
engineering and bachelors of science 


degrees reported among the lowest 
median incomes ($46,700 and 
$46,000, respectively). 

Women continue to earn less than 
men. “When comparing medians in 
the groups with less than 15 years of 
experience, females earn consistently 
less than men at all levels of experi¬ 
ence,” the survey states. 

The 125-page study can be ordered 
for $59.95 (IEEE member price) or 
$79.95 from Publication Sales, IEEE 
Service Center, 445 Hoes Lane, P.O. 
Box 1331, Piscataway, NJ 08855- 
1331. 
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Advance Announcement 


Conference On 
Software Maintenance—1989 

/ m /r r\ \ Omni International Hotel 

(CSM-89) SK,, 


THEME: Closing The Gap Between Technology and Practice 


The Conference on Software Maintenance-1989 (CSM-89) will gather software manag¬ 
ers, developers, maintainers, and researchers to discuss new solutions to the continu¬ 
ing challenge of software maintenance and software maintainability. 


Sponsors: 

IEEE Computer Society-Technical 
Committee on Software Engineering 


In Cooperation With: 

/^—N ACM/SIGSOFT-Special Interest Group on 
(aCITu Software Engineering 


❖ 


The Institute of Electrical and Electronics 
Engineers, Inc. 




Software Maintenance Association (SMA) 


f A£ x National Institute of Standards and 
Technology (NIST) 


American Society for Quality Control (ASQC) 


Conference and Tutorial Registration Fees 

Advance Registration Fees-Until September 25,1989 
Conference Only: 

Members = $220 Nonmembers = $275 Students - $70 

Tutorials Only: , 

Members = $210 per tutorial Nonmembers = $260 per tutorial Students - $210 per tutorial 

Late/On-site Registration Fees-After September 25,1989 
Conference Only: 

Members = $265 Nonmembers = $330 Students = $70 

Tutorials Only: _ , . . . . 

Members = $250 per tutorial Nonmembers = $310 per tutorial Students - $250 per tutorial 


If attending both the conference and a tutorial(s), please add the appropriate fees for your total registration fee. 


To obtain a copy of the full CSM ’89 advance program, contact: Conference Department, IEEE Computer Society, 1730 Massachusetts 
Avenue, NW, Washington, DC, 20036, (202) 371-1013. 










Advance Announcement 


Conference On 
Software Maintenance—1989 


Omni International Hotel 
Miami, Florida 
October 16-19,1989 




Monday, October 16, 1989-The following all day tutorials will be held from 9:00am-5:00pm: 

Tutorial 1: “Impact Analysis"-Dr. Robert S. Arnold, Software Productivity Consortium 
Tutorial 2: “Software Metrics”-Dr. Horst Zuse, Technical University of Berlin 

Tutorial 3: “CASE, Reverse Engineering, and Design Recovery”-Dr. Elliot J. Chikofsky, Index Technology Corporation 
Tutorial 4: “Expert Systems Software Maintenance”-Steven W. Oxman, OXKO Corporation 

Tuesday, October 17, 1989-The conference will begin with a keynote address “Software Reengineering by Visualiza¬ 
tion” by Mr. Thomas J. McCabe, McCabe and Associates, Inc. In addition, the following paper sessions and panels will be presented: 

IA. Session-Software Maintenance Methods 

IB. Session-Software Metrics I 

2A. Session—Debugging and Testing Methodology 

2B. Panel Discussion-’Process-Focused Models of Software Maintenance” 

3A. Panel Discussion-“CASE Supported Maintenance Environment” 

3B. Session—Software Metrics II 

Wednesday, October 18, 1989-The day will open with a keynote address delivered by Dr. Harlan D. Mills, University 

of Florida and Information Systems Institute. Dr. Mills’ address is entitled “Bringing Professional Rigor Into Software Maintenance.” The 
following paper sessions and panels will follow: 

4A. Session—Tools for Software Maintenance I 

4B. Session—Reverse Engineering 

5A. Session-Tools for Software Maintenance II 

5B. Panel Discussion-“Non-traditional Perspectives on Software Maintenance” 

6A. Panel Discussion-Bridge Technologies for Software Maintenance” 

6B. Session-Configuration Management 

Thursday, October 19,1989 -Dr. Norman F. Schneidewind, Naval Postgraduate School, will deliver the plenary session 

address entitled “Software Maintenance: The Need for Standardization.” The following two sessions and a panel discussion will end the 
day at 12:30pm: 

7A. Session-Software Maintenance Practice 

7B. Session-Knowledge Engineering in Software Maintenance 

Closing Panel Discussion-'Software Maintenance and Practice” 


Hotel Information 

The conference will be held at the Omni International Hotel, Biscayne Blvd. at 16th Street, Miami, Florida 33132, (305) 374-0000. A spe¬ 
cial block of sleeping rooms are being held for CSM ’89 attendees. Please mention that you are attending CSM ’89 and you will be given 
the reduced rate of $80.00 for a single or double room. All reservations must be received by the hotel before September 17,1989. Reserva¬ 
tions received after this date are not guaranteed and will be accepted on a space-available basis only. 










STANDARDS 


Editor: Fletcher J. Buckley, GE Aerospace, MS: 145-3, Moorestown, NJ 08057-0927; phone (609) 866-6350; fax (609) 866-6439; Compmail+ f.buckley 


A course of action for the Standards section 


As indicated under the heading of 
this department, I am how the stan¬ 
dards editor for Computer. In 
attempting to lay out a course of 
action for this column, I would like to 
do three things: 

(1) Identify existing standards 
information, 

(2) Continue the previous editor’s 
approach to address the significant 
issues associated with standards, 
and 


(3) Provide a forum for additional 
discussion. 

This month’s discussion on stan¬ 
dard metrics is part of that continu¬ 
ing effort to address the significant 
issues associated with our com¬ 
munity. 

Topics for future issues are cur¬ 
rently projected to cover; 

(1) Transnationalization of IEEE 
standards, 


(2) Misuse of standards, and 

(3) Reusability standards. 

As part of the aforementioned 
forum, I encourage you to suggest 
topics on the major issues 
associated with standards, submit 
articles (of about 1,500-1,600 words) 
covering those topics, and provide 
further discussion on the content of 
the column by letter or Compmail +. 
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Standard set of useful software metrics is urgently needed 


Fletcher J. Buckley, GE Aerospace 

Today, an urgent need exists for a 
standard set of useful software metrics. 

For a metric to be useful on the fac¬ 
tory floor means that 


(1) the definition of the metric is 
unambiguous, 

(2) there must be a prescribed objec¬ 
tive method by which the data can be 


gathered and processed, 

(3) the actions to be taken as a result 
of that information are objective, 
finite, and timely, and 

(4) the metric must have intrinsic 
worth. 

To illustrate some of the problems 
with metrics, consider reliability. The 
typical systems developer knows hard¬ 
ware reliability methodology and needs 
a system that works. Furthermore, the 
developer sees no need to give up previ¬ 
ously used system specification tech¬ 
niques just because software is part of 
the system. 

Therefore, following the hardware 
reliability approach, the developer 
divides the system into hardware and 
software components and assigns to 
each component a metric called mean 
time between failure (MTBF). 

The unfortunate part of this 
approach is that those techniques and 
that metric are inadequate in the soft¬ 
ware world. For example, in the hard¬ 
ware world, we can build models and 
objectively calculate what the MTBF is 
going to be long before the hardware is 
built. Further, we can take a set of 
known finite steps to increase that 
MTBF. For example, we can insert 
high-reliability components and cool 
down the hot spots. These actions will 
cost money, but we can project with a 


Defining some useful metrics 


(1) The Branch Metric is the num¬ 
ber of modules in the system in 
which all the branches have been 
executed at least once, divided by 
the total number of modules in the 
system. 

(2) The Decision Point Metric is the 
number of modules in the system in 
which all the decision points have 
been exercised at least once, divided 
by the total number of modules in the 
system. 

(3) The Error Message Metric is the 
number of error messages in the sys¬ 
tem that have been demonstrated, 
divided by the total number of error 
messages in the system. 

(4) The Domain Metric is the num¬ 
ber of modules in the system in 
which at least one legal entry and 
one illegal entry in every field in 
every input message has been cor¬ 


rectly processed, divided by the total 
number of modules in the system. 

(5) The Requirements Execution 
Metric is the number of requirements 
in the Software Requirements Speci¬ 
fication that have been Correctly 
demonstrated, divided by the total 
number of requirements in that spec¬ 
ification. 

(6) The Problem Trouble Report 
Metric is the number of open prob¬ 
lem trouble reports on a given proj¬ 
ect. These may be further divided 
into subcategories for more precise 
definition; for example, the number 
of open problem trouble reports 
against a particular category of 
document (Software Requirement 
Specifications) or the number of 
open reports against a particular 
computer program. 
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fair degree of accuracy how much the 
MTBF will increase for a fixed, 
predetermined, additional cost. 

Conversely, the software world has 
no methodology for spending addi¬ 
tional money to obtain a quantized 
incremental improvement in the reliabil¬ 
ity of a software product. The harsh 
bottom line is that, although many very 
good people have been working on the 
problem of software reliability, there 
are very few people who will play the 
game called “You Bet Your Company” 
to meet a quantized software reliability 
figure. 

In looking for useful metrics in the 
software world, the six defined in the 
accompanying sidebar have cropped up. 
They meet all the previously identified 
criteria, including direct value. 

To a software test director, the first 
five ensure that: 

(1) All the code has been executed at 
least once, 

(2) There are no unreachable error 
messages, and 

(3) The programmers have paid some 
attention to the requirements. 

Furthermore, to a software test direc¬ 
tor, these metrics can form part of the 
criteria used to determine when the soft¬ 
ware has completed integration and is 
ready for formal acceptance test.* 


* To avoid confusion, note that 

(a) the first metric covers branches, not paths. 
Furthermore, this metric should be normally satis¬ 
fied at initial testing of the modules (unit test 

as opposed to system test); and 

(b) the use of the first five metrics should be 
considered a necessary but not sufficient part of 


Materials available 


Additional information may be 
obtained by circling the indicated 
number on the Reader Service Card 
(standards may be ordered through 
any of the Computer Society offices 
or directly from the IEEE): 

•The IEEE Standards Manual, 
February 1989, RS No. 180. 

•The IEEE Standards Style Man¬ 
ual, February 1989, RS No. 181. 

•A Guide to IEEE Standards Devel¬ 
opment, February 1989, RS No. 
182. 

•IEEE Standards Bearer subscrip¬ 
tion information, RS No. 183. 

•Information on IEEE Standards 
Working Group P1045, Software 
Productivity Metrics, RS No. 184. 


The first five are product metrics; 
they directly address the end product. 

The sixth is a process metric; when 
plotted against time, it shows where the 
process is heading. If the number of 
open problem trouble reports continues 
to increase, then something drastic 
needs to be done from a management 
viewpoint. Relative to this metric, it 
should be noted that there is no attempt 
at categorization (easy or difficult, sim¬ 
ple or complex, etc.). Actually, the situ¬ 
ation is self-correcting. The easy faults 
to correct—the corrections that take lit¬ 
tle effort or resources—will be closed 
out as soon as possible. What remains 
will either be new items or serious long¬ 
term problems. 

In looking at other metrics in the 
software world, very few meet the 
criteria identified above. Some metrics 
depend on subjective criteria (function 
points), others provide indicators where 
additional unspecified work can be 
done (counts of specific types of 
instructions), and still others lack any 
intrinsic value. Some even further per¬ 
form an extensive analysis of the code 
'structure. When last seen, the correcta¬ 
ble information from those metrics was 
more directly related to the lines of 
source code in the module (source file) 
than it was to the information metric 
derived by processing the module 
through an algorithm. 

It all winds up into the “so what” 
criteria. When all the dust has settled, 
who is going to take what defined 
action based on what criteria? If that 
question cannot be satisfactorily 
answered for you in your environment, 
then reorient the metrics effort early 


•Information on IEEE Standards 
Working Group P1061, Software 
Quality Metrics, RS No. 185. 

•Information on the Accredited 
Standards Committee X3 Informa¬ 
tion Processing Systems project, 
“Technical Report on Source 
Code Metrics," RS No. 186. 

•Computer Society Publications 
Catalog, RS No. 201. 

In addition, the March 1989 Com¬ 
puter Society Standards Status 
Report can be ordered from the Com¬ 
puter Society Press, Los Alamitos, 
California, by calling (800) CS- 
BOOKS or (714) 821-8380 in Califor¬ 
nia. The cost is $10. 
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and avoid the embarrassment of having 
collected mountains of data with no real 
end use. 

For further reading, your attention is 
invited to: 

(a) “Quantifying Software Valida¬ 
tion: When To Stop Testing?” an arti¬ 
cle on pp. 19-27 of the May 1989 issue 
IEEE Software by J.D. Musa and A.F. 
Ackerman. The article provides a good 
introduction to what can be done today 
in software reliability. 

(b) IEEE Std 982.1-1989, “IEEE 
Standard Dictionary of Measures to 
Produce Reliable Software.” 

(c) IEEE Std 982.2-1989, “IEEE 
Guide for the Use of Standard Mea¬ 
sures to Produce Reliable Software.” 

(d) Programming Productivity, a 
1986 Capers Jones book published by 
McGraw-Hill that provides a realistic 
assessment of some of the more popular 
metrics. 

Those wishing to participate in ongo¬ 
ing work in metrics may obtain addi¬ 
tional information by circling the 
appropriate numbers on the Reader Ser¬ 
vice Card as listed in the sidebar, 
“Materials available.” 
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CALL FOR PAPERS 



International Conference on Information Technology 

commemorating the 30th anniversary of 
The Information Processing Society of Japan (IPSJ) 

October 1-5, 1990 in Tokyo, Japan 



Theme: Information Technology Harmonizing with Society 


Conference Chairperson: 

Takuma Yamamoto (Fujitsu) 

Program Committee 
Chairperson: 

Haruhisa Ishida 
Computer Centre 
University of Tokyo 
2-11-16 Yayoi 
Bunkyo-ku, Tokyo 113 
Japan 

Phone: + 81-3-818-0287 
E-mail: 

infojapan90@u-tokyo.ac.jp 

Program Committee 
Membres: 

Y. Ahzai (Keio Univ.) 

S. Domen (Hitachi) 

K. Hirose (Waseda Univ.) 

T. Katayama (Tokyo Inst, of 
Technology) 

Y. Matsushita (Oki) 

K. Murakami (NTT) 

M. Nagao (Kyoto Univ.) 

T. Nishizeki (Tohoku Univ.) 

S. Sato (Fujitsu Labs) 

N. Suzuki (IBM Japan) 

H. Tanaka (Univ. of Tokyo) 

S. Uemura (Tokyo Univ. of Agri. 

& Tech.) 

K. Ushijima (Kyushu Univ.) 

R.P. Brent (Australian National 
Univ.) 

C.S. Kim (Seoul Univ., Korea) 
H.T. Kung (CMU, U.S.A.) 

C.V. Ramamoorthy (UCB, U.S.A.) 
N. Seshagiri (National 
Informatics Centre, India) 
W.Wahlster (Univ. of 
Saarlandes, Germany) 

Wang Chengwei (Inst, of 
Sys. Eng., China) 

C.K. Yuen (National Univ. of 
Singapore, Singapore) 

Organizing Committee 
Chairperson: 

Kyoichi Shimazaki (NTT) 


The IPSJ will hold an International Conference on Information Technology 
(InfoJapan ’90) in 1990, celebrating its 30th anniversary. The objective of this 
conference is to present and discuss topical 21 st century research and develop¬ 
ment themes. The development of information technology must not cause human 
alienation. Rather, there must be a harmonization with humanity; a harmonization 
which will be acceptable to all generations and helpful toward the creation of a new 
civilization. 

Conference Tracks and Sessions 

A. Software technology 

OS in distributed processing, Performance & reliability in OS 
Programming language for everybody, Method & techniques 

B. Parallel computing 

Computer architecture, Algorithms, Software technology 
Application, Commercial parallel computers 

C. Artificial intelligence 

Theory and foundation, Natural language understanding 
Computer vision 

Tools for artificial intelligence systems and their applications 

D. Advanced information systems 

Information modelling 

Computer communications and integrated communications 
Distributed processing, Advanced database systems 
Computers and education, Computers and people 

E. Special topics 

Fifth generation computers, OSI 
Sigma project, Machine translation 
Microprocessor, Neurocomputers 
Supercomputing 
Papers 

Send six copies of the full paper (typed in English on A4 or letter-sized sheets in 
double space), in 3700-4500 words including the title, name, affiliation, address 
and phone number of the author, the track category into which the paper would fit, 
and a 150-word abstract to the chairperson of the Program Committee. The paper 
must be received by February 1,1990. 

Official language: English 








PRODUCT REVIEWS 


Editor: Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd., Scituate, MA 02055; Compmail+, r.eckhouse 


An amazing array of Generic CAD products 

William Gleason 


What follows is a look at some ca¬ 
pable and inexpensive products from 
Generic Software. Before I begin, I’ll 
tell you what you should look for when 
choosing a CAD tool. Next are my re¬ 
views of Generic’s 2D and 3D drawing 
packages, along with the DotPlot 
printer/plotter utility. The serious user 
would do well to consider these latest 
offerings from Generic Software (8763 
148th Ave. NE, Redmond, WA 98052, 
phone (206) 885-5307 or (800) 228- 
3601). 


Criterion for selecting a 
CAD package 

The relative costs of computer-aided 
design systems have come down at an 
amazing rate over the last decade. Four 
years ago, computer-aided design and 
drafting systems cost $100,000 plus 
per workstation. Now a new generation 
of packages allows you to configure an 
entire CAD system and obtain capabili¬ 
ties similar to AutoCAD’s for less than 
$3,000, with software costing less than 
$500 and hardware — including output 
devices — less than $2,500. 

CAD packages, whether expensive or 
inexpensive, do essentially the same 
thing: assist in the design and drafting 
process. Design requires conceptualiza¬ 
tion, while drafting needs good hand- 
eye coordination and familiarity with 
drafting tools. CAD packages typically 
can’t help you design, but they can help 
you draft. Even without good hand-eye 
coordination, you can produce great 
drawings with CAD packages. 

Because CAD packages do not typi¬ 
cally help with drawing conceptualiza¬ 
tion, they do not speed up the design 
process. Like writing, however, design¬ 
ing entails a great deal of editing, and 
CAD packages speed the editing pro¬ 
cess considerably. 


What to expect in a CAD 
system 

All CAD packages use primitives or 
entities to create drawings. These in¬ 
clude points, straight lines, parallel 
lines, rectangles, polygons, arcs, 
circles, ellipses, curves, and multipoint 
curves. I have separated relevant fea¬ 
tures into two categories: capabilities 
that an application should include and 
those you would like to see it include. 

All CAD applications require you to 
set the scale of the drawing, which 
translates the drawing’s unit of meas¬ 
ure into real-world measurements. You 
might choose a scale of 1 inch to 10 
feet in a drawing of a building, for 
example. 

A package should offer grid and snap 
capabilities to help you align graphics 
elements properly. A grid displayed on 
the screen indicates intersections at 
regular, specified distances. Snaps act 
like magnets, pulling the cursor to the 
nearest point on the grid, the endpoint 
of a line, the intersection of certain 
lines, the midpoint of a circle, or the 
nearest quadrant. 

You should be able to specify entity 
placement to exact coordinates on the 
screen using a keyboard, digitizer, or 
mouse. Movement around the screen 
should be provided by Zoom and Pan 
commands. The Zoom command in¬ 
creases or decreases the size of objects. 
The Pan command allows for move¬ 
ment around the screen without chang¬ 
ing the size of the objects on the 
screen. 

The package should provide window 
capability. “Windowing” is the pro¬ 
cess of drawing a box around the de¬ 
sired area on the screen and then using 
editing features to perform specified 
operations on the objects within the 
box. Erase, Move, and Rotate are three 
typical commands generally found in 
window subdirectories. The software 


should permit you to rotate objects, re¬ 
size them, fill them with color or 
hatching patterns, join two endpoints, 
and clean up drawings using trim and 
extend commands. 

Editing features should permit fillet¬ 
ing, to create smooth curves between 
arcs. The package should also include a 
mirror function, which enables you to 
draw half of the object, then reflect 
that half over a center axis to get the 
remaining half. 

You should be able to structure 
drawings by layers to simulate acetate 
overlays. You should also have a di¬ 
mensioning capability. The package 
should allow you to place dimension 
lines parallel to the lines they describe, 
whether those lines run horizontally, 
vertically, or at an angle. The package 
should also provide circle diameter and 
radius dimensioning. 

The CAD software should allow you 
to store symbols or images on disk and 
to insert these stored images into new 
drawings. It should also provide rota¬ 
tion and scaling of symbols. 

A CAD package should allow you to 
share files with other packages. The 
current standard is the ANSI-approved 
International Graphics Exchange Stan¬ 
dard (IGES). The format is actually 
ASCII, which you can edit using a 
word processor. 

Some of the “nice to have” features 
include 

• a tolerancing capability; 

• undo or unerase commands, which 
permit undoing or unerasing the 
last operation performed; 

• a bill of materials module, which 
permits labeling of components to 
provide parts and components lists; 
and 

• macros and programming lan¬ 
guages to allow menu alteration 
and unique command creation. 

These features, both the shoulds and 
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nice to haves, guide my evaluation of 
CAD package. 


What is Generic CADD? 

Generic CADD, version 3.0, is a vec¬ 
tor-based rather than integer-based sys¬ 
tem. This means that each line in 
CADD represents a vector calculated 
when it draws an object. Integer-based 
systems assign to each vertex of an ob¬ 
ject an absolute coordinate rounded to 
a user-defined minimum unit. The line 
segment between the two vertices is 
defined as a series of points. This 
makes an integer-based system faster 
for some functions, but less accurate. 

A math coprocessor, if installed, per¬ 
forms the intensive mathematical func¬ 
tions much faster. The difference 
shows up as a significant increase in 
speed of some functions. 

Generic CADD comes in three basic 
applications or levels. Each includes 
features and capabilities that match a 
predetermined level of expertise and 
user requirements. 

Level 1, priced at $49.95, is de¬ 
signed for entry-level users who want 
CAD at a minimal price. It provides 
capabilities for drafting tasks such as 
creating charts and graphs. It supports 
an unlimited number of fonts. 

Level 2, priced at $99.95, includes 
all of the basic features plus snaps, 
single-line trims, comer cleans, ex¬ 
tends, dimensioning, chamfers, and fil¬ 
lets. The package targets the intermedi¬ 
ate user who will use CAD on a regular 
basis. 

Level 3, designed for the power user, 
costs $199.95. It targets design and 
drafting professionals. Features include 
dozens of editing commands, a macro 
command language, and area fill and 
hatching. It also provides support for 
plotters and most popular digitizers. 
Level 3 supports Expanded Memory 
Specification (EMS) to enable produc¬ 
tion of larger drawings. 

In addition to the three levels, the 
user can also purchase a number of 
software symbols libraries that range in 
price from $24.95 to $74.95. 

The basic hardware needed to run 
Generic CADD is an IBM PC or com¬ 
patible with at least 512 Kbytes of 
RAM and DOS 2.0 or higher. The com¬ 
pany highly recommends 640 Kbytes 
of RAM and a math coprocessor. EMS 
memory is a useful addition. Generic 
CADD also supports a large number of 
graphics boards, mouse systems, and 
plotters. 

You can enter data using the key¬ 
board, a mouse, or a digitizer. The key¬ 


board is best for entering point coordi¬ 
nates and making selections from a 
menu. The mouse and digitizing tablets 
are best for screen drawing. Many us¬ 
ers prefer digitizing tablets because of 
their similarity to traditional drafting 
tools. 

Installation was straightforward and 
relatively easy. I had the software up 
and running in about five minutes. The 
package provides a configuration appli¬ 
cation to specify the type of computer, 
graphics card, printer, plotter, mouse, 
and digitizer. 

Using Generic CADD. Generic 
CADD’s drawing screen has a list of 
commands along the right side of the 
display. A command entry area is lo¬ 
cated at the lower left. An indicator 
shows the current location of the cursor 
in user-selectable units. 

With just a few keystrokes you can 
change the colors of all the screen dis¬ 
plays. You can remove the video menu 
entirely, thus freeing the screen area 
for graphics use. 

The commands that appear on the 
video menu are complete words: draw, 
component, line, and so forth. You can 
evoke commands from the keyboard 
using their two-letter abbreviations. 
You will find a mouse or digitizer 
highly desirable; you can use them in 
concert with keyboard commands. The 
program also gives you an easy way to 
back out of almost any operation, by 
using the Esc key. 

Generic CADD organizes its menus 
hierarchically into a root menu and as¬ 
sociated submenus. A highlighting cur¬ 
sor moves vertically along the menu 
bar, while the graphics cursor moves 
everywhere on the screen. You select 
commands by pressing the middle but¬ 
ton on the mouse (the right button on a 
two-button mouse). You enter points 
with the left button. You can program 
extra buttons on a pointing device, or 
you can program function keys to initi¬ 
ate any command or sequence of com¬ 
mands. Pressing the spacebar repeats 
the last command. 

The system comes up in line-draw¬ 
ing mode. You can enter lines by sim¬ 
ply placing points. A stretching line 
appears as a visualization aid. Each 
line segment you create has its own 
distinct endpoints. 

Layer and component management 
are excellent, as are snaps and grids. 
Geometry creation and peripheral sup¬ 
port are also very good. The Window 
Copy command permits you to dupli¬ 
cate objects and move and rotate them 
into the proper location. 

Text management in Generic CADD 
is good. It offers multiple as well as 


user-definable fonts. You can replace 
portions of existing text blocks without 
having to retype the entire block. The 
package does not permit you to justify 
text, automatically align it to match a 
given space, or run it along an arc or 
curve. 

For symbol libraries, the package al¬ 
lows access to a DOS-style directory 
without leaving the program, but you 
must return to the graphical portion of 
the program and enter the name of the 
symbol library to load it. Nor can you 
simply point at a file name to load it, 
as you can with the menus for the sym¬ 
bol libraries. This is a disadvantage 
because you need to remember file 
names to retrieve them. You cannot 
generate a bill of materials from the 
package. 

Test drawings. To test Generic 
CADD, I created a simple architectural 
drawing and renderings of several me¬ 
chanical objects. I subsequently modi¬ 
fied each by stretching and changing 
the dimensions. 

I constructed the drawings with 
straight lines, curves, circles, and arcs 
using the package’s relative coordinate 
and snap features. I used the arc and 
fillet commands for the round parts. 

The Window Mirror command allowed 
me to copy half objects across the cen¬ 
ter of the object. I then drew construc¬ 
tion lines from the main drawing to 
create the side view. To hatch the solid 
areas of the object in the side view, I 
used the fitted hatch command. 

The auto dimensioning package 
made dimensioning quite simple. It 
contains five different line terminators 
along with definable witness line length 
and offset, text height and placement, 
and many other capabilities. 

I had little trouble increasing the 
various dimensions of the objects using 
the Scale Window command. With the 
keyboard coordinate input, this feature 
allowed me to make the changes in a 
few minutes. 

For the architectural drawing, I used 
the double line, orthogonal snap, and 
intersection cleanup features. The 
zoom feature, using windows and pan 
capabilities within the drawing, helped 
me size the drawing and its details. 

Generic CADD summary. Overall, 
Generic CADD is an extremely good 
production drafting system for the 
price. It conforms to all of my “should 
have” requirements and “nice to 
have” features with the exception of 
tolerancing. The extensive software 
symbols libraries are easy to use and 
reduce redrawing of symbols to those 
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unique to your environment. Electrical 
and electronics engineers can choose 
among seven templates ranging from 
commercial and residential electrical 
symbols to microprocessor symbols. 

The documentation provided for both 
the extensive add-ons and the Generic 
CADD software itself is easy to read 
and organized properly to allow you to 
find the features you need in a mini¬ 
mum of time. Frequent tips and cau¬ 
tions keep you from going astray. The 
software warranty runs for 60 days, 
with replacement of defective disks 
permitted for up to 90 days. Technical 
support is offered, and I found it to be 
excellent. A toll-free number is not 
available, unfortunately. The com¬ 
pany’s support number was often busy 
when I called. 

The package is an excellent value 
from every point of view. Furthermore, 
Generic Software’s continued develop¬ 
ment of both allied compatible prod¬ 
ucts and program improvements will 
keep this software current with the im¬ 
proving PC-based CAD marketplace. 

Reader Service 21 

Three-dimensional CAD 

For many professionals, CAD has 
been too expensive to buy solely for its 
three-dimensional capability, but not 
any more. Software for professional 3D 
rendering emphatically separates CAD 
as a design tool from CAD as a draw¬ 
ing tool. The ability to draw a 3D pro¬ 
jection with shaded surfaces and a 
minimum of 16 colors is more than a 
fancy advertising claim; it’s an essen¬ 
tial tool for the serious designer. 

Solid modeling has been attractive to 
leaders in architectural and mechanical 
design for some time. But these appli¬ 
cations place such high demands on 
hardware that even large CAD systems 
have not yielded adequate perform¬ 
ance. Designers are unable or unwilling 
to tolerate delays of more than a sec¬ 
ond or two in the viewing of updated 
images regardless of their complexity. 

Not all CAD software has full three- 
dimensional capability. Some software 
can only draw plans or elevations and 
cannot combine them in a useful three- 
dimensional display. With three-di¬ 
mensional software, you can critique 
forms, spaces, lighting, scale, and any 
other aspect of a design in an accu¬ 
rately simulated environment. You can 
also test human response with ani¬ 
mated sequences that walk through the 
space. Short of being there, 3D CAD is 
the best way to experience the building 
and study alternative views. 


Generic 3.D 

Generic 3.D, version 2.2, although 
not in the minicomputer/workstation 
environment class, does permit a par¬ 
tial step toward that end. It has the ca¬ 
pability to create three-dimensional, 
mathematically defined models. The 
applications defined by Generic Soft¬ 
ware include: 

• Engineering prototypes of new 
products 

• Architectural models of buildings 

• Sculpture or graphic design rendi¬ 
tions 

• Plumbing and ventilation systems 
for building contractors 

Generic 3.D permits display of a 
model in a variety of formats — with 
hidden lines removed, with solid sur¬ 
faces rendered in different colors, or 
with a perspective effect. Features 
include: 

• Multiple views: the screen can be 
divided into two or four separate win¬ 
dows with a different view in each 
window. 

• Graphics Manipulation Language: a 
full-featured macro programming lan¬ 
guage to perform complex operations 
or repeat command sequences. 

• Moving light source: a movable 
point that acts like the sun; move it and 
the model is shaded for a more realistic 
effect. 

• Drawing and image files: any view 
that can be seen on the monitor can be 
saved, loaded directly into Generic 
CADD, or printed. 

• Construction plane: facilitates 
building complex objects or models. It 
has its own coordinate frame and can 
be moved to any position or orientation 
in space. 

• 3D rendering: allows filling of the 
model, creating realistic 3D representa¬ 
tions of the object, including solid rep¬ 
resentations with edges highlighted and 
solid representations with shading from 
a light source (if your system has a 
board with 256 colors). 

System requirements. This software 
will run on any IBM PC XT, AT, or 
compatible computer with a floppy 
disk drive and at least 512 Kbytes of 
RAM (640 Kbytes and a hard drive rec¬ 
ommended). It requires DOS 2.0 or 
higher. Because 3D modeling is a com¬ 
putationally intensive process, a math 
coprocessor is highly recommended. 
Like Generic CADD, Level 3, the pro¬ 
gram supports a large number of graph¬ 
ics cards and monitors. It installs 
quickly and easily, and the well-written 


documentation offers plenty of tips to 
keep you on track. 

System operation. Generic 3.D, like 
Generic CADD, is menu driven. You 
call up command windows using func¬ 
tion keys. The command window 
serves two purposes. It lists command 
options and gives you the status of the 
models being drawn. You select the 
“status” mode by pressing the Alt key 
and any one of the 10 function keys. 
Pointing devices also let you move 
from mode to mode. I highly recom¬ 
mend using a mouse to create the ob¬ 
jects if you value your time — mouse 
use speeds up the operation vastly. 

Commands appear in the command 
window at the bottom of the screen. 
The Command/Status window serves 
two purposes. It either lists command 
options, called subcommands, or it 
gives information about the status of 
the model. You can easily back out of 
almost any operation by using the Esc 
key. 

When you draw an object (or ob¬ 
jects) with Generic 3.D, it builds a 
mathematically defined 3D model 
viewable from any angle. Controls al¬ 
low interaction with the object through 
the user interface. This interface con¬ 
sists of 

• commands that let you make, 
move, and modify objects and 
groups of objects; 

• tools to help with these tasks; and 

• systems to check the status of 
things. 

The object is projected on the screen 
in two ways. The first, called ortho¬ 
graphic projection, provides the true 
proportions of the object. The second, 
called perspective projection, distorts 
the model and gives it depth so that ob¬ 
jects further away are smaller. You 
control view width and distance to pro¬ 
vide the desired perspective. Changing 
the zoom factor also changes the view 
width. 

Generic 3.D excels in three-dimen¬ 
sional drawing, particularly in its abil¬ 
ity to define multiple views. The pro¬ 
gram provides two or four display win¬ 
dows with a different user-selected 
view in each window. It allows almost 
unlimited freedom in viewing the se¬ 
lected model and enables work in steps 
as small as 0.0001 millimeter. 

Generic 3.D summary. Generic 3.D 
is a true three-dimensional modeler 
that defines solids through faces, verti¬ 
ces, and edges. You can produce solid 
or wireframe models in a very short 
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time. The construction plane facilitates 
building complex objects in their own 
coordinate frame and can be moved to 
any orientation space. 

The solid modeling capabilities of 
Generic 3.D are truly significant for 
the price. The ability to create intricate 
real-life models creates a working en¬ 
vironment that permits efficient visu¬ 
alization and easy modification of 
those models. The ability to create 
drawings, view them as wireframe rep¬ 
resentations, then use the rendering ca¬ 
pabilities to fill or shade the wire¬ 
frame model are unique at the price. 

Generic 3.D contains plane-defini¬ 
tion capabilities found in more expen¬ 
sive micro- and mini-based CAD pack¬ 
ages. You can work in view and 3D co¬ 


ordinates to define geometry. The abil¬ 
ity to work in views other than stan¬ 
dard orthographic projection makes 
definition of complex objects easy. 
Priced at $349.95, it is hard to pass up. 

Reader Service 22 


DotPlot 

Included with the Generic CAD 
products was a utility program for 
printers, called DotPlot, version 3.0. I 
used it to plot the objects I developed 
while testing Generic CADD. It sup¬ 
posedly turns a dot matrix printer into 
a plotter, producing crisp, high-resolu¬ 


tion drawings up to 14 inches wide and 
96 inches long. Drawings can be ro¬ 
tated 90 degrees and fitted to the paper 
size or scaled to precise requirements. 
DotPlot supports 100 different dot ma¬ 
trix and laser printers, including color- 
on-color printers. 

The output depends, of course, on 
the printer used. The picture provided 
by the old standby bottom-of-the-line 
Star Gemini-1 OX looked about like 
what you would expect. When used on 
the Epson LQ line of printers, DotPlot 
produced output as claimed — of a 
quality suitable for reproducing draw¬ 
ings. It’s handy and certainly cheaper 
than a plotter. 

Reader Service 23 
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More than a fourth-generation 
language for VAX/VMS. Fourth- 
generation languages are easier to 
use, more flexible, more powerful, 
and much faster than 3GLs like Co- 
bol, Fortran, Pascal, Basic, or C. 
Such a 4GL is Accent R, Version 
10.09, produced by National Infor¬ 
mation Systems, 1190 Saratoga 
Ave., San Jose, CA 95129, phone 
(408) 985-7100, available for VAX/ 
VMS systems (VMS version 4.2 or 
greater). For installation you need 
27,000 blocks of disk space (13.5 
Mbytes). There are 15 simple steps 
for installation. 

The most important characteristic 
of Accent R is that it is also a rela¬ 
tional database management system 
and creates a total applications de¬ 
velopment environment. The Accent 
R programming language includes a 
framework, called Application Mod¬ 
els (useful for reducing program¬ 
ming time), many debugging tools, 
strong error analysis possibilities, 
easy syntax checking, clear and 
easy-to-understand commands, and 
windowing capabilities (for proto¬ 
typing and developing complex ap¬ 
plications). 

The Reporter command is useful 
for generating report programs with 
a simple fill-in-the-blanks approach. 
Menu Maker creates menus to direct 
the execution of an application, in¬ 
cluding access to modules written in 
3GLs or access to other applica¬ 


tions, such as word processing or 
spreadsheets. It provides password 
security. 

Other important features include 
the Data Base Library (which con¬ 
tains and dynamically updates all 
the programs created by the user), 
more than 80 system functions 
(which eliminate many common 
programming tasks), an SQL gate¬ 
way to the Sybase RDBMS, and a 
gateway to the ShareBase System 
(for high-speed retrieval). 

Accent R’s Data Base Manage¬ 
ment System DB-Mach2 includes 
the following characteristics: mul¬ 
tiple indexes on the same data set 
(to eliminate the need for additional 
sorting), index keys that can contain 
multiple fields, multiple record 
types, 3D arrays, variable-length 
and compressed records, up to 4,000 
fields and 500,000 characters per 
record, binary key search for se¬ 
quential files, and direct access to 
first and last records. 

The documentation is extensive 
and well written, but quite difficult 
to read (too small of characters). 

The price is between $14,000 and 
$200,000. Accent R is a powerful 
and useful product, recommended 
for VAX/VMS users. — M. Dediu 


CAE for analog circuit design. 

Analog Workbench is a set of inte¬ 
grated software modules designed to 


run on high-performance worksta¬ 
tions (VAXstations, Sun, Apollo, 
HP). Another version runs on the 
IBM PC AT with a 110-Mbyte disk. 
Mainly, the Analog Workbench is 
an interactive tool for designing and 
simulating analog circuits. 

Analog Workbench aids designers 
creating circuits in almost any ana¬ 
log application. An important ad¬ 
vantage in using this product is that 
you can design a circuit, attach 
simulated test instruments, and 
evaluate circuit performance before 
building the first prototype. 

Two practical features are mouse- 
controlled menus and simulated in¬ 
strument displays. In fact, all tests 
and measurements use simulations 
of instruments familiar to the ana¬ 
log designer, such as oscilloscopes, 
spectrum and network analyzers, 
frequency sweepers, and multime¬ 
ters. Also, SPICE Plus provides ac¬ 
curate circuit simulation. 

A time-consuming part of circuit 
simulation is the creation of device 
modules. The Analog Workbench 
includes a standard set of basic cir¬ 
cuit elements. A General Device Li¬ 
brary Module, available as an op¬ 
tion, contains hundreds of semicon¬ 
ductor and IC devices widely used 
in analog design. Also available is a 
Power Design Module, which can 
simulate different elements of a 
power system. 

Another useful option, the Smoke 
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Changing data into working information 

William Gleason 


Most of the information systems I 
work with are done in database-ori¬ 
ented languages like dBase. Some use 
compiled Clipper and Quicksilver pro¬ 
grams to increase data sorting speeds. 

Engineers and project managers gen¬ 
erally don’t want to wade through an 
entire database of 1,000 records unless 
absolutely necessary. They prefer to 
approach the control process through 
statistical analyses. Thus you find 
j yourself dealing with software that 
does database tasks well, but is not 
quite so spiffy when it comes to turn¬ 


ing the number of tasks delinquent into 
a histogram form presentable to man¬ 
agement. There is a lot of pressure to 
provide statistically oriented graphics 
material, generally in “overhead” 
viewgraph form, to offer a general pic¬ 
ture of the relative performance status 
of, for example, action plans or the 
tracking of changes to government 
contracts. 

“And why,” you are asked, “doesn’t 
the same application that contains the 
data also provide the capability to gra¬ 
phically portray the statistics we track 


on a weekly (monthly, yearly) basis? 
Why should you have to transfer the 
data to a graphics package to provide 
information? Isn’t that a wasted step?’ 

The answer is that database pro¬ 
grams don’t, without extensive pro¬ 
gramming effort, do graphics very 
well. And yes, transferring data to a 
graphics program is an added step. 


A solution 

Flipper, from ProWorks (PO Box 
1635, Hermiston, OR 97838), provides 
one solution. This graphics program, 
written in C, contains a library of func¬ 
tions callable from Clipper or dBase 
application programs to produce x-y 
graphs, pie charts, and drawings. It 
supports most graphics cards, dot ma¬ 
trix and laser printers, and HPGL-com- 
patible plotters. 

Flipper adds about 80-100 Kbytes of 
extra program overhead to your appli¬ 
cation when not used as an overlay. 

Flipper consists of the Flipper Li¬ 
brary, an overlay program, and 
Grafplus. The latter interfaces with pe¬ 
ripheral devices. A demo program and 
a test database file that come with the 
system provide a working example of 
how to use the library. 

A light-bar menu across the bottom 
of the screen permits selection of the 
database and data elements. The first 
step is to select a database. A help fea¬ 
ture (pressing the FI function key) dis¬ 
plays all the database files on the disk. 

Flipper will load data into a prede¬ 
fined storage buffer. The first column, 
the x-axis data, can be numeric, charac¬ 
ter, or date. The remaining columns 
can be plotted as lines, points, bars, or 
stacked bars on the same graph. You 
can continue to enhance this graph, se¬ 
lecting up to six additional variables. 
The x and y axes are automatically 
scaled, but you can manually override 
the values. Flipper can draw any num¬ 
ber of graphs on the graphics screen at 
the same time. 

A memory-resident replacement for 
the DOS Graphics.com is included with 
Flipper. This program will print the 
graphics screen to any printer. 

The latest release of Flipper from 
ProWorks adds many new features, in¬ 
cluding mouse support, two indepen¬ 
dent y axes, viewports, and an overlay 
manager. In addition, the font-writing 
system now allows Flipper IV to read 


Alarm Module, helps to determine 
safe operating conditions for the de¬ 
sign, thus eliminating problems 
caused by overstressed circuits. 
Smoke Alarm evaluates a circuit for 
peak (or average) power dissipation, 
peak voltage, peak current, and 
maximum junction temperature. 

Also worth mention is a Statisti¬ 
cal Analysis Module, which simu¬ 
lates the effects of component pa¬ 
rameter tolerances on the perform¬ 
ance of the circuit being designed. 
You can simulate worst-case per¬ 
formance, use Monte Carlo tech¬ 
niques to determine the combined 
effect of variations in component 
tolerances, and identify circuit per¬ 
formance sensitivity to individual 
components. 

Analog Workbench is produced 
by Analog Design Tools, 1080 E. 
Arques Ave., Sunnyvale, CA 94086, 
phone (408) 737-7300. It works 
with the following networks: Apollo 
Domain Network, Sun Network File 
System (using Ethernet), and 
AnalogLink (with a standard RS- 
232 interface). Documentation is 
good and comprehensive. Technical 
support is competent and friendly. 
The price of the product is between 
$14,500 and $60,000, depending on 
the number of modules (options). I 
thought it a highly professional 
CAE product that I would recom¬ 
mend for any analog circuit de¬ 
signer. — M. Dediu 


DEC color printer. Digital 
Equipment (1-800-DIGITAL) has 
produced the Companion Color 
Printer, which is a quiet, compact 
desktop printer that combines good 
quality graphics with near-letter- 
quality text for $1,695. There are 
two models: the LJ250, with DEC- 
423 and RS-232 serial interfaces; 
and the LJ252, with a Centronics- 
type parallel interface, for Digital or 
mixed systems environments. 

This printer uses disposable car¬ 
tridges, each containing a print head 
and thermal ink-jet supply. This 
makes maintenance quite simple. 

The speed is 167 cps burst, 90 cps 
throughput; the noise is less than 45 
dBs; and the time between failures 
is about 10,000 hours. 

It supports Digital systems 
through ANSI-compatible text and 
color pixel protocols, and IBM PCs 
and compatibles under MS-DOS 
through the Hewlett-Packard HP- 
PCL protocol. The resolution for 
color is 180 x 180 dpi for seven col¬ 
ors or 90 x 90 dpi for 255 colors. It 
weighs less than 10 pounds, and the 
carry-in service warranty is good 
for one year. 

The printer takes about two to 
four minutes per page for a color 
graphics output. 

I found the Companion Color 
Printer easy to use, quiet, and reli¬ 
able. The manual is well written. 

— M. Dediu 
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and write GEM-compatible fonts. You 
can also use fonts from Ventura Pub¬ 
lishing, or any of the 140 font files in¬ 
cluded with Flipper IV. A font editor 
allows for the creation of new fonts 
and icons for use with your Clipper 
program. 

Flipper IV now has its own non¬ 
memory-resident print-screen driver, 
which is royalty free. It allows you to 
select and change printers from within 
your Clipper program, expand the im¬ 
age on the printer, and print a portion 
of the screen. 

The mouse support includes the abil¬ 
ity to set and select hot areas on the 
screen and draw circles, lines, and 
boxes using the mouse. 

Flipper Graphics Library links di¬ 
rectly with Nantucket’s Clipper Com¬ 
piler and also provides a memory-resi¬ 
dent program that prints graphs to dot 
matrix or laser printers. System capa¬ 


bilities include: 

• Support for all graphics modes, 
with automatic switching between 
modes. 

• Automatic scaling of axes. 

• Support for dot matrix, laser, and 
HP plotters. 

. CGA, EGA, VGA, and Hercules 
graphic modes. 

• Multiple graph types on one screen, 
limited by space. 

• Unlimited points on a graph. 

• Low-level drawing functions. 

• Save and restore of pictures from 
any portion of the screen. 

• Overlay manager. 

Writing an application was simple. 
I’ll spare you a detailed explanation of 
the code we developed, however. In 
half a day we developed a line graph 
superimposed over a bar graph that 
tracked one year of milestone perform¬ 


ance data on a NASA program. The re¬ 
sults satisfied the project manager and 
are now used as a part of the monthly 
management review with the customer. 
Furthermore, the application is effort¬ 
less to use. The most important point is 
to ensure the correctness of the data re¬ 
flected in the database. We now take 
the graphics output for granted as a 
true representation of program- per¬ 
formance. In short, the focus is on the 
data and how to correct the problems it 
represents. 

Flipper bridges a troublesome gap 
between data and its depiction. It has 
proven itself to be a most worthwhile 
addition to our toolbox of graphics 
tools. Its value is demonstrated often in 
requests for a chart “to satisfy this one 
time, special, NASA Center Director 
briefing” ... at noon today. 

Reader Service 24 


Can machines help improve your writing skills? 


Noah Davids 

Writing has always been a signifi¬ 
cant means of communication, but in 
today’s age of interlinked networks and 
electronic mail, it sometimes serves as 
the only means of communication. This 
article will review three products de¬ 
signed to help you write better: 
RightWriter from RightSoft (4545 
Samuel St., Sarasota, FL 34233, phone 
(813) 923-0233), Grammatik III from 
Reference Software (330 Townsend, 
Suite 123, San Francisco, CA 94107, 
phone (415) 541-0222), and PC Style 
from ButtonWare (PO Box 5786, 
Belleview, WA 98006, phone (206) 
454-0479). 

1 evaluated each product by having it 
process three samples of my writing: a 
section of a user’s manual (47,413 
bytes), a magazine article (39,812 
bytes), and a letter (1,642 bytes). I also 
constructed a special file containing all 
sorts of bad examples gleaned from a 
writing book and a grammar text 
(3,746 bytes). 

Product description, 
packaging, and license 
agreement 

All the products run on IBM PCs or 
compatibles and require DOS 2.0 or 
higher. RightWriter version 3.0 re¬ 
quires 384 Kbytes of memory. It comes 
with a 196-page manual, two 5.25-inch 


disks, and one 3.25-inch disk. The 
well-written, clear manual is spiral- 
bound, so it opens flat to any page you 
want. The program is not copy pro¬ 
tected, and the license agreement 
grants “to you a nonexclusive transfer¬ 
able license to use this software prod¬ 
uct on one single-user computer at a 
time.” According to the technical sup¬ 
port group, this means it can be in¬ 
stalled on several single-user systems 
as long as only one system is in use at 
a time; for example, home and work 
systems. RightWriter lists for $95. 

Grammatik III version 1.02 also re¬ 
quires 384 Kbytes of memory. It comes 
with a 127-page manual and three 5.25- 
inch diskettes. While the manual pro¬ 
vides lots of details, it is easy to read. 
The program is not copy protected, and 
the license agreement states that you 
can use Grammatik III on one com¬ 
puter. Individuals can also use it on 
any other system that they personally 
own. Grammatik III lists for $99. If 
you need a 3.5-inch disk, you send in 
the coupon included in the package and 
another $15. 

PC Style requires only 40 Kbytes of 
memory. The 23-page manual comes as 
a file on the 5.25-inch distribution 
disk. This is not an ASCII file, so you 
have to print the manual with a special 
program also on the distribution disk. 
PC Style is shareware. 

Shareware programs usually offer 
several levels of registration. Increas¬ 


ing the level of registration increases 
the cost but also provides more bene¬ 
fits. For $15 you can get either the lat¬ 
est PC Style program disk or one year 
of technical support. For $30 you get 
both the latest program disk and one 
year of technical support. Businesses 
must register a copy of the product for 
each machine that it will run on. 


Installation 

Installation of RightWriter consists 
of copying six files off the distribution 
disks. They take 434,722 bytes of disk 
space. The four required files take 
434,331 bytes. The first time you run 
RightWriter, it asks for your name and 
type of monitor (color, monochrome, 
not PC compatible). After that, when 
you start RightWriter the initial screen 
says that the product is licensed to you 
and states that the product can be used 
on one single-user computer and you 
can make a backup. If you have not 
supplied input and output files on the 
command line, you must press Return 
to progress beyond this screen. A one- 
paragraph demo document that points 
out some of the system features is a 
good starting point. 

Installation of Grammatik III was 
also very simple. You just stick disk #1 
into drive A and run the install pro¬ 
gram. During the installation process 
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you also select the word processor that 
you use. I had only one problem with 
the installation process. A Readme.txt 
file contains information not in the 
manual. It is displayed by a screen-at- 
a-time viewer program. The 25th line 
of this program shows the path name of 
the file being viewed. Because 1 placed 
Grammatik III down a few levels in my 
directory tree, the 25th line was so 
long that it wrapped around to the next 
line, and the first line of the display 
scrolled off the screen. This was a mi¬ 
nor problem, easily corrected, because 
Readme.txt is an ASCII file that you 
can display after the installation is 
complete. 

All 22 files took 877,605 bytes on 
my hard disk. The minimum configura¬ 
tion consists of three files (269,408 
bytes). The help file, which is not re¬ 
quired, adds another 81,137 bytes. To 
do spell checking requires the master 
and user dictionary files (149,138 
bytes). The setup program is 65,115 
bytes. Certain length-sensitive word 
processors require special conversion 
programs. These programs range in 
size from 29,040 bytes to 38,096 bytes. 

Grammatik III comes with a demo 
file that shows the types of errors it 
finds and lets you correct them. I 
thought it a very impressive demo. 

You install PC Style by copying the 
nine files off the distribution disk. 

These nine files require 94,053 bytes 
of disk space. A minimum configura¬ 
tion consisting of the command file 
and a profile file requires only 26,883 
bytes. 

The special program used to print 
the manual also lets you view the man¬ 
ual on the screen. A menu lists each 
section. At the end of each screen of 
text you get a “Press any key to con¬ 
tinue” prompt. If you press the PgDn 
key, the next page will skip by without 
waiting for you to respond to the 
prompt. You cannot go backwards to 
reread a previous page or search for a 
keyword. Having the manual in a file 
should allow you to use all the display 
and searching capabilities of the com¬ 
puter, but this mechanism prevents 
that. 


Customization 

RightWriter allows extensive cus¬ 
tomization. You can set a writing style 
based on both education level (general 
public, high school, or college) and 
type of writing (general business, tech¬ 
nical, manual, proposal, or fiction). 
These settings control the rules used, 
the problems checked, and the words to 


appear in the review list in the sum¬ 
mary section of the output. 

You can check for 12 grammar, 21 
style, 16 usage, and 10 punctuation 
problem types. The problem type I 
most appreciate is the missing or mis¬ 
used comma and semicolon. 

The summary appended to the end of 
the document can also be customized. 

It can contain up to six indexes, includ¬ 
ing three different readability indexes. 
It can include statistics about the text, 
such as the number of words, syllables, 
sentences in the document, average 
number of words per sentence, syl¬ 
lables per word, and percentage of 
prepositions. You can select any of 12 
different sentence structures that, if 
found in the text, will cause specific 
recommendations to be added to the 
summary. The words-to-review list in¬ 
cludes any jargon, slang, commonly 
misused words, negative words, and 
uncommon words in the text. These 
words are defined in a modifiable dic¬ 
tionary. You can also create new spe¬ 
cialized dictionaries. The only limita¬ 
tion on the dictionary is that it can 
handle only single words, not phrases. 
You can also add to the summary a fre¬ 
quency chart of the words used in the 
text. Finally, you can set the defaults 
for file names, suffixes, and directories 
or change your monitor type. You can 
have multiple configuration files speci¬ 
fied on the command line. 

RightWriter is fully compatible with 
21 word processors. Fully compatible 
means that RightWriter will accept a 
document created by the word proces¬ 
sor and the word processor will accept 
a document marked up by RightWriter. 
If the word processor has the capabil¬ 
ity, the comments inserted into the 
document will use a special font to off¬ 
set them from the text. Among these 
word processors are Microsoft Word, 
Multimate, WordPerfect, and Word¬ 
Star. RightWriter will also accept a 
straight ASCII file and can automati¬ 
cally convert the documents of another 
12 word processors into ASCII before 
processing. One missing function is the 
ability to change the screen colors. 

The ability to customize Grammatik 
III is also extensive. You can decide 
the treatment of file names, quoted 
items, and capitalized words in the 
middle of a sentence. You can set the 
character used to mark a suspected 
construct or to indicate that a section 
of text should not be checked. You can 
indicate if you want suggested correc¬ 
tions to accompany the suspect mark, 
spelling to be checked, a summary file 
to be produced, or output to go to the 
printer. You also indicate the word 
processor you use. You can create mul¬ 


tiple configuration files and indicate on 
the command line which one to use so 
different types of text can be treated 
differently. 

A separately purchased Grammatik 
III utility pack allows you to edit the 
phrases in the phrase dictionaries and 
change the screen colors that Gramma¬ 
tik HI uses. I feel that these functions 
should be part of the standard product. 
The utility pack also allows you to 
make Grammatik III memory-resident, 
compare your text to some standard 
reference works, and remove the marks 
that Grammatik III adds to the text file. 

Grammatik checks for more than 40 
problem types, from incorrect punctua¬ 
tion to incorrect word usage to bad but 
correct usage. Problems are identified 
and corrections suggested. In addition, 
a summary list can be output that lists 
three different readability scales as 
well as statistics about sentence con¬ 
struction. You can also get just the 
summary if that is all you want. You 
can have the problems marked in the 
original file or any other file that you 
choose. If you mark the original file, 
then its unmarked state is saved in a 
backup file. 

You can customize everything about 
PC Style. Thjs really isn’t much. The 
default screen colors are black and 
white, but you can set the foreground 
and background colors to whatever you 
want. The ranges of each parameter 
used to grade the text can all be 
changed, and the lexicon of personal 
and action words can be modified. You 
can have up to 300 words in the list, 
each word limited to 15 letters. The 
profile is a standard ASCII file, which 
you can edit with any ASCII editor. 

Like RightWriter and Grammatik III, 
PC Style lets you have multiple pro¬ 
files for different types of writing. 


User interface 

A menu-based interface lets you se¬ 
lect the function you want RightWriter 
to perform or change the system’s con¬ 
figuration. The menu format is full 
screen. The options occupy a column in 
the middle of the screen, with status in¬ 
formation on the bottom few rows of 
the screen and your name and the pro¬ 
gram’s version number in the top few 
rows. You select an option by position¬ 
ing the cursor with the arrow keys and 
pressing Return or by pressing the key 
that corresponds to the first letter of 
the option description. You can bypass 
the menus when analyzing a document 
and removing the markings in a previ¬ 
ously analyzed document by using file 
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PC-Stylist report for: , 

..Narticle 



Sentences: 

373 



Words: 

5994 

Poor...Best 

Words per sentence: 

16.0 

17.+#- 

-+7.0 

% Long words: 

12.4 

14.+#- 

-+2.0 

% Personal words: 

2.5 

0.0+--#—- 

-+9.0 

% Action verbs: 

1.5 

0.0+-#- 

-+2.5 

Syllables per word: 

1.6 

2.5+-—#— 

-+1.0 

Reading grade level: 

11.3 

18.+-—#— 

-+6.0 


POOR FAIR AVERAGE GOOD EXCELLENT 

Readability +--+.-+-#--+—.+----+ 

Personal tone +-.-l—#.-+-..+.—“+-+ 

Action +-—H--+—.-#-“*•+-.-+ 


Figure 1. PC Style tabulates statistics on your text, then shows the results on¬ 
screen. 


Table 1. Execution times and errors found by the tested grammar checkers. 



RightWriter 

Grammatik III 

PC Style 


Number of 

Execution 

Number of 

Execution time 


errors 

time 

errors 

(mark only rule is 

off) 

Article 

289 

13:30 

301 

11:50 

0:52 

Letter 

ID 

0:53 

7 

0:48 

0:05 

Document 

329 

12:30 

314 

14:20 

0:47 

Example 

39 

2:02 

89 

2:14 

0:09 


names and switches on the command 
line. 

The document is actually checked in 
a batch mode, meaning there is no 
interaction. A display shows you the 
number of words in the document and 
then displays RightWriter’s progress so 
you have a good idea how far through 
the document you are and how long it’s 
going to take. Comments go into an 
output file; the input file remains un¬ 
changed. When analyzing a document, 
the program first removes any previous 
marks so you don’t have to remove 
them by hand. You can also have the 
system just remove the marks without 
adding new ones. 

Grammatik III executes in either a 
batch or interactive mode. In interac¬ 
tive mode the user interface consists of 
a menu bar at the top of the screen and 
drop-down menus. To select a drop¬ 
down menu, you can use the arrow 
keys to move to a menu title on the 
menu bar and press the Return key, or 
you can press the Alt key and the first 
letter of the menu title. Once the drop¬ 
down menu appears, you use the arrow 
keys to move to an option and then 
press the Return key. Many of the op¬ 


tions in the drop-down menus also have 
hot keys that allow you to bypass the 
drop-down menu. The context-sensitive 
help is good but slow. 

When Grammatik III identifies a 
problem in the file, the program pre¬ 
sents it in a context window along with 
a line or two above and below the prob¬ 
lem area. The exact number of lines de¬ 
pends on the length of the lines in the 
text. The problem type and a suggested 
correction appear in another window. 
For each problem, you can mark it and 
continue, skip it, skip all problems of 
the same type, or edit it. If you choose 
to edit, you can change all the text in 
the context window even if it has noth¬ 
ing to do with the problem. Also, the 
program does not rescan your correc¬ 
tion to make sure that you corrected the 
problem and did not create a new one. 

I prefer the batch mode. The prob¬ 
lems are marked and suggestions 
(maybe) added to the file without inter¬ 
action on your part. A sentence counter 
shows Grammatik Ill’s progress 
through the file, but for it to be useful 
you have to know how many sentences 
are in the file. The default Grammatik 
III options are not very useful, only 


adding marks to the file. This identifies 
the problem, but does not give you any 
clues about the type of problem or sug¬ 
gestions for how to fix it. For that you 
must turn off the “mark only” flag. 

PC Style has a simple user interface. 
The program asks for the name of the 
file to be graded, then displays a screen 
that shows the grading statistics as 
both percentages and a graph. There is 
also a percent-done graph. You can 
specify the file name and a profile 
from the command line if you want. 
Mistakes in the profile are just ignored, 
so figuring out there is a mistake and 
then finding it can be difficult. 


Evaluation 

Neither RightWriter nor Grammatik 
III performed very well on the bad ex¬ 
amples file. Both missed most of the 
more subtle types of errors, like shifts 
in tertse or subject, plus most of the 
punctuation errors. Both systems iden¬ 
tified the simpler types of errors, like 
passive voice, split infinitives, and 
long sentences. Grammatik III disap¬ 
pointed me more because it states right 
on the cover that it uses artificial intel¬ 
ligence techniques. RightWriter also 
uses AI techniques, but it doesn’t boast 
about it. 

RightWriter found some problems 
not reported by Grammatik III, and 
Grammatik III reported some problems 
not found by RightWriter. In general, I 
found that RightWriter reported fewer 
things that I dismissed as not really 
being errors. RightWriter also reported 
more things that I did consider errors. 
For instance, it reported more missing 
or misused commas. 

Grammatik III does report two very 
useful types of problems that Right- 
Writer does not find. First, Grammatik 
notes the use of two words when there 
should only be one, such as using 
“with out” instead of “without.” Sec¬ 
ond, Grammatik III also reports when 
homonyms or other frequently misused 
words (like accept and except) appear 
in the text. The usefulness of this is 
lessened because it always reports 
when these words appear, even if they 
are used correctly. This can generate a 
lot of false reports, and I was tempted 
to turn off the rules that check for 
these types of words. RightWriter does 
not report on homonyms at all, but re¬ 
ports potentially misused words in the 
summary. 

I was also tempted to turn off the 
Grammatik III rule that checks for 
“sexist usage.” With this rule on, 
Grammatik III reports all uses of any 
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word that denotes sex, even if the word 
is appropriate. For example, in “Mr. 
Smith called to say he would be late,” 
it will flag “he.” This makes the 
“sexist” rule so verbose that I found it 
useless. On the other hand, RightWriter 
misses a lot of phrases that can be con¬ 
sidered sexist; for example, “the girls 
in the typing pool.” This makes its 
sexist rule also just about useless. 
However, when it does report a prob¬ 
lem, it’s a real one. 

When RightWriter identifies a prob¬ 
lem, it includes an error number and a 
brief description. You need to look the 
error code up in the manual for a com¬ 
plete description of the problem and 
(in some cases) how to fix it. Some 
problems are also reported with a ques¬ 
tion. I found that I tended to dismiss 
these question messages. If the pro¬ 
gram isn’t sure, why should I worry 
about it? As a result, I found that inter¬ 
preting the output from RightWriter 
took more effort than interpreting the 
output from Grammatik III. 

Grammatik III messages are more di¬ 
rect. Grammatik III also has a spelling 
checker. Using it just about doubled 
the batch execution time, and I found it 
disappointing when running interac¬ 
tively. One switch allows you to add a 
word to a “user dictionary” and an¬ 
other lets you ignore a word in the rest 
of the document. Nothing lets you 
automatically correct a word in the rest 
of the document after the first correc¬ 
tion. Also, your correction is not 
checked again to make sure it’s cor¬ 
rect. The advice for spelling correction 
consists of a single suggestion for the 
correct spelling. 

PC Style is a very different type of 
program. It does not offer any advice 
on specific grammar or style problems, 
like split infinitives or sexist language. 
Instead, it tabulates statistics on the 
text and then presents them on the 
screen (see Figure 1). This is very 
similar to the summary portions of 
both RightWriter and Grammatik III. It 
also gives you the option of printing 
the screen. 


Technical support 

My contacts with RightSoft tech sup¬ 
port were all very satisfactory. The 
person I spoke with was very knowl¬ 
edgeable and courteous. She also re¬ 
turned phone calls and called back 
when she said she would. Combine this 
with the 800 number and I would rate 
technical support for RightWriter 
excellent. 

I had two contacts with Grammatik 


Ill’s tech support, one very good and 
one not so good. During the not-so- 
good contact, the customer support per¬ 
son told me that he could not answer 
my questions, but that he would check 
and get back to me. He never did. On 
the plus side, both times I was con¬ 
nected to tech support very quickly and 
was not put on hold. The tech support 
number is not an 800 number. 

I had no contact with ButtonWare’s 
tech support. PC Style was so easy to 
use and understand that I never needed 
any help. They do include a tech sup¬ 
port number, but it’s not an 800 number. 


Execution times and total 
errors found 

Table 1 lists the amount of time that 
it took to analyze each of the docu¬ 
ments (Grammatik III was done in 
batch mode). I ran these tests on a 
4.77-MHz PC clone with a disk cache 
large enough that all disk reads came 
from the cache (writes went directly to 
the disk). Times include loading the 


program and its dictionaries (which 
also came from the cache). I used de¬ 
fault parameters in all cases with the 
exception that I turned off the “mark 
only” rule in Grammatik III. This 
made Grammatik III produce output 
similar to that of RightWriter. 


Summing up 

PC Style’s summary analyses are 
useful and significantly faster than ei¬ 
ther RightWriter or Grammatik III. 
However, I need the more detailed 
analysis and suggestions offered by the 
other two. Of the other two, I prefer 
RightWriter. Its results were more use¬ 
ful to me and included far fewer re¬ 
ports of things that I did not consider 
problems. I felt that its customization 
capabilities were slightly better than 
Grammatik Ill’s and the tech support 
more responsive. Also, the 800 number 
for tech support was a plus. 

RightWriter: Reader Service 25 
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Data acquisition board 


Richard Eckhouse 

Typically, the choice among real¬ 
time data acquisition boards for the PC 
looks like a ho-hum decision. To begin 
with, a number of board manufacturers 
offer a good selection of seemingly 
similar choices. Thus, the purchase de¬ 
cision is based on the number of chan¬ 
nels, dynamic range, and reputation of 
the vendor. Occasionally, the choice 
breaks down to the slight difference 
one board manufacturer offers over an¬ 
other, such as price, number of digital- 
to-analog channels, or support soft¬ 
ware. But, for the sophisticated user of 
PC-based data acquisition boards, the 
real issues are resolution and skew be¬ 
tween samples on different channels. 

For understandable economic rea¬ 
sons, the typical data acquisition board 
for the PC has provided 8 or 16 analog 
input lines with 10- or 12-bit resolu¬ 
tion. Usually a multiplexer sits be¬ 
tween the analog inputs and a single 
sample and hold circuit, which is in 
turn connected to a single analog-to- 
digital conversion unit. Because the 
different analog signals are sampled 
consecutively, there is a skew in the 
sample times, often overlooked by (or 
not significant to) the average user. 


The DT2809 

Those users requiring both greater 
resolution and simultaneous analog 
measurement haven’t had much to 
choose from. Typically, you could find 
boards with simultaneous sampling, 
but they offered few channels, lower 
(12-bit) resolution, and lower conver¬ 
sion rates. However, the introduction 
of the DT2809 board from Data Trans¬ 
lation has changed all this, because it 
offers eight simultaneous channels of 
analog input, 16-bit resolution, and a 
16-kHz (using a “Read A/D with 
DMA” command) throughput rate at a 
list price of $2,495. 

The input range for the eight chan¬ 
nels is fixed at + 10 volts, and the 
channels are all single-ended. Conver¬ 
sion time is 30 ps per channel. An in¬ 
teresting and very valuable feature of 
this board is that autocalibration occurs 
on power-up and continues as you use 
the board. Part of the calibration proc¬ 
ess continues each time an A/D conver¬ 
sion is performed. After 72,192 con¬ 
versions, the background calibration 
completes. Based on available stan¬ 
dards I used while testing the board for 
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Data Translation’s DT2809 data acquisition board has eight simultaneous 
sample and hold inputs with 16-bit resolution. 


this evaluation, the calibration process 
appeared to be extremely accurate. 

Both an external trigger and an ex¬ 
ternal clock can be supplied to this 
board for analog-to-digital conver¬ 
sions. Input impedances are quite high 
at 100 megaohms, so circuit loading is 
not a significant factor. Digital conver¬ 
sions are available as offset binary 
only. 

While this review concentrates on 
the analog input conversion process, 
many other features of the DT2809 de¬ 
serve comment. One is the other data 
acquisition sections available on the 
board. Specifically, there are two 
DACs, each providing 12-bit resolution 
and an aggregate data rate of 33 kHz. 
Another feature is the 16 lines of digi¬ 
tal I/O, which can be configured as two 
8-line inputs or outputs. The digital I/O 
is TTL compatible with a sinking capa¬ 
bility of 0.25 milliamperes and an out¬ 
put current of 24 ma. The DMA can be 
set for either bipolar or unipolar out¬ 
put, with jumper-selectable ranges of 
0-10V, 1-5V, and ±10V, ±5V, and 
± 2.5V at 5 ma minimum. 


Using the DT2809 

Data Translation ships the 2809 with 
a hefty manual and a 5.25-inch disk 
containing sample programs — typical 
packaging for its boards. The manual 


explains setting up the board using the 
jumpers that specify the board’s base 
address and direct memory access 
channel, as well as the ranges of the 
two DACs. Next comes a discussion of 
the command/status and data in/out 
registers. Because of the on-board mi¬ 
croprocessor, the programming of the 
board is extremely simple. As a result, 
the example programs are all given in 
interpreted Basic. Even the novice user 
will find it easy to walk through these 
examples, from basic functioning to 
DMA data gathering. 

Since the DT2809 is port addressed, 
programming of the board takes the 
form of "wait-for-ready” followed by 
“issue-command” or "read/write 
data.” In addition to a programming 
tutorial with six sample programs, an 
additional 14 programs cover the use 
of the board. The example programs 
cover every mode from analog-to-digi- 
tal and digital-to-analog conversion (in 
both immediate and DMA modes) to 
digital input and output. 

Part of the learning process is to use 
and modify the example programs. 
Some programs simply provide you 
with text output giving the board’s 
status or the results of a conversion. 

To really access this board, you should 
have the $179 DT707 screw terminal 
panel, which brings all 50 signals at 
the back of the board out front where 
you can conveniently reach them. In 
my case, I attached a function genera¬ 


tor and a scope to the analog input and 
output terminals, respectively, and then 
“played” with the example programs 
to gain complete familiarity with this 
device. 

But what if you want to use the 
DT2809 board as part of an experi¬ 
ment? Here, you really need to write 
specialized software tailored to your 
application. Once again you have a 
number of choices. For one* you can 
purchase PCLab. This $299 software 
subroutine library is common to the en¬ 
tire DT2801 series and DT2806 IBM 
computer-compatible boards. Support¬ 
ing analog as well as digital data trans¬ 
fers from or to the Data Translation 
boards, this library includes a resident 
device driver and language-specific 
function calls for initializing, configur¬ 
ing, controlling, gathering, producing, 
and error checking within your pro¬ 
gram. The languages supported include 
Microsoft Assembler, Basic, Quick Ba¬ 
sic, C, Fortran, and Pascal as well as 
Turbo C and Pascal. Each subroutine 
call is thoroughly documented, with 
plentiful examples. If anything really 
stands out about this package, it is the 
overwhelming nature of it. 

PCLab noticeably lacks software for 
the analysis and display of the analog 
and digital data. So, a second choice, 
assuming you don’t wish to write your 
own, would be one of the numerous 
packages (Asyst, LabTech Notebook, 
1LS, DADiSP, etc.) just made for this. 
Since the DT2809 is compatible with 
the 2801 series, most of these packages 
will run right out of the box without 
special drivers and the like. For those 
readers who missed it and want to un¬ 
derstand what you can do with such 
software systems, the March 1989 is¬ 
sue of Computer (pp. 81-88) covered 
both Asyst and ILS in detail. 


Final comments 

Astute readers will note that this re¬ 
view seems to have found nothing to 
criticize about the DT2809. This is so 
because the board works exactly as ad¬ 
vertised, is thoroughly documented, 
and offers a functionality (eight simul¬ 
taneous 16-bit conversions at up to 16 
kHz) not generally available elsewhere. 
This functionality accounts for the pre¬ 
mium price compared to other boards 
in the $900-$ 1,200 range. 

Contact Data Translation at 100 
Locke Dr., Marlboro, MA 01752-1192, 
phone (508) 481-8620. 
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1989 IEEE INTERNATIONAL WORKSHOP 
ON DEFECT AND FAULT TOLERANCE IN 
VLSI SYSTEMS 

October 22-24,1989 

Hyatt Regency Westshore Hotel, Tampa, Florida 


Workshop Purpose! Advanced techniques of defect/fault control and tolerance are 
being developed to enhance manufacturability and productivity of integrated circuit chips, 
VLSI systems, and wafer scale integrated circuits. This workshop brings together the 
designers and researchers from industry and universities who are implementing these 
objectives by means of fault-tolerant architectures, testability, CAD tools, novel pack¬ 
aging techniques, characterization of yield losses, and yield modeling. The following 
topics are addressed: 

• Defect and fault tolerant architectures 

• Defect and fault tolerant memories 

• Techniques for yield enhancement 

• Fault models and defect models 

• Statistical modeling of defects and yield 

• Packaging techniques for WSI and 3-D VLSI 

Co-Chairmen are C. H. Stapper, IBM USA, and V. K. Jain, University of South Florida, 
USA. The Program Chairperson is G. Saucier, Institut National Polytechnique de 
Grenoble, France. 


• Repair and restructuring techniques 

• Testable designs for VLSI and WSI 

• High density hybrids 

• CAD tools 

• Experimental studies 


Registration Information: 

Registration 

Registration 

Before Sept. 15 

After Sept. 15 

IEEE Members 

$190 

$230 

Non-Members 

$235 

$290 

Student-Members 

$50 

$50 

Please make checks payable to: 

DFT - VLSI'89 


and send to: 

D. L. Landis 



Department of Electrical Engineering 

University of South Florida, 


Tampa, Florida 

33620 


Hotel Information: Hyatt-Regency-Westshore Hotel 

Telephone: (813) 874-1234 


$88 per night, single occupancy 
$88 per night, double occupancy 

Reservations should be made directly with the hotel; the cut-off date for the above rates 
is September 22, 1989. 
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NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail+, n.hays 


Unix workstation claimed to be fault-tolerant 


Concept Data Resources claims that 
its Unix-based Hyperstation worksta¬ 
tion is fault-tolerant. The new computer 
runs on AT&T’s Unix System V, 

Release 3, with a port planned to 
Release 4 when it becomes available. 

Hyperstation employs Motorola’s 
68030 microprocessor, plus mirrored 
hardware and software for fault toler¬ 
ance, according to the company. The 


system is reportedly rated at 9 MIPS for 
a single computer and up to 144 MIPS 
for a 16-CPU configuration. 

Prices start at $30,000 for a basic 
configuration, which supports 32 users, 
32 Mbytes of memory, two CPUs, and 
100 Mbytes of disk storage. 
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Overlay transfers existing drawings to CAD 


Foresight Resources has introduced 
Drafix CAD Overlay, which the com¬ 
pany says assists in the conversion of 
existing hard-copy drawings to CAD. 
The program uses a scanned, bit¬ 
mapped image of the existing drawing. 
It displays the scanned image, allowing 
the user to trace over the image using 
the drawing and editing tools provided 
by Drafix CAD Ultra. The raster image 
acts like another layer in the Drafix 


drawing and can be rotated, enlarged, 
scaled, and so forth. The final result is 
a vector CAD image. 

Drafix CAD Overlay requires Drafix 
CAD Ultra 3.00 or higher, including a 
video adapter, monitor, and pointing 
device. It supports a variety of 
scanners. 

Drafix CAD Overlay costs $195. 
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Computer optimized for multiple users 


Point 4 Data claims that it has 
optimized its new Mark 6S Series com¬ 
puter for use by up to 32 users. The new 
computer operates at a 160-ns instruc¬ 
tion execution cycle time, according to 



the company, and features a 32-bit bus 
operating at 33.3 Mbytes per second. It 
supports up to 4 Mbytes of extended 
memory. It also has 128 Kbytes of on¬ 
board memory, implemented in 35-ns 
static RAM. 

The Mark 6S runs IRIS (Interactive 
Real-time Information System), the 
company’s proprietary operating sys¬ 
tem. Application software can be writ¬ 
ten in IRIS Business Basic, SMbasic, 
Basic Four Business Basic, and Thor¬ 
oughbred Basic. 

The tower-style cabinet includes a 
power supply, fan, processor, controller 
boards, and 5.25-inch storage 
peripherals. 

A basic Mark 6S system comes with a 
6.25-MIPS CPU, 2 Mbytes of extended 
memory, a 170-Mbyte ESDI Winchester 
disk drive, a 150-Mbyte 0.25-inch car¬ 
tridge tape streamer, a DMA mul¬ 
tiplexer with 16 ports, and an IRIS 
license. It costs $22,995. 

Optional systems include a 2.3-Gbyte 
helical scan cartridge tape and a 
0.5-inch, reel-to-reel magnetic tape. 


33-MHz Deskpro out 

Compaq Computer has added to its 
desktop PC line with the 33-MHz, 
80386-based Deskpro 386/33, Models 
84, 320, and 650. The new machine uses 
Compaq’s Flex architecture and 64 
Kbytes of cache memory. It has eight 
expansion slots and room for five stor¬ 
age devices for a maximum of 1.3 
Gbytes of internal mass storage. 

The system board includes a video 
graphics controller and standard 
peripheral interfaces, leaving six expan¬ 
sion slots available for add-in boards. 
The machine accepts up to 16 Mbytes of 
memory in a 32-bit memory slot. 

Prices are $10,499 for Model 84, 
$14,999 for Model 320, and $17,999 for 
Model 650. 
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New SAA applications 

IBM says that its OfficeVision family 
of office-automation software is its first 
major System Application Architecture 
software application. The new software 
family reportedly provides integrated 
office functions across the OS/2, MVS, 
VM, and OS/400 operating systems. 
Functions include document prepara¬ 
tion, filing, electronic mail, decision 
support, and calendar scheduling. The 
products are available in 20 languages. 

OfficeVision/2 LAN Series costs 
$750 for OS/2 or $210 for DOS. Office- 
Vision/MVS has a graduated primary 
license charge ranging from $15,130 to 
$51,000 and a graduated annual license 
charge ranging from $2,670 to $9,000, 
or a graduated monthly license charge 
ranging from $605 to $1,815. OfficeVi¬ 
sion/VM’s graduated primary license 
charge ranges from $8,500 to $51,000, 
while the graduated annual license 
charge ranges from $1,500 to $9,000 
and the monthly charge ranges from 
$605 to $1,815. OfficeVision/400 has a 
monthly license charge of $945 or either 
a one-time charge from $2,885 to 
$28,640 or a graduated primary license 
charge from $1,890 to $18,740, plus a 
graduated annual license charge from 
$335 to $3,310. 
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Point 4’s Mark 6S comes in a tower 
configuration. 
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Prime beefs up EXL 300 and 50 Series lines with new models 


Prime Computer has added several 
new models to its EXL 300 Series and 
50 Series lines of computers, as well as 
creating a new series, the EXL 1200, 
based on multiprocessors from Sequent 
Computer Systems. 

The entry-level MBX joins the Unix- 
based EXL 300 family. Built around 
Intel’s 80386 CPU, the new system sup¬ 
ports from two to 10 users, a maximum 
of 33 asynchronous communications 
lines, and up to 417 Mbytes of disk 
capacity. It features simultaneous 
access to applications and communica¬ 
tions software based on the Unix, DOS, 
and Pick operating systems. Prices start 
at $8,200 and range up to $30,845. Six 
configurations are available. 

The 2850 joins the 50 Series of com¬ 
puters, based on the company’s propri¬ 


etary Primos operating system. The 
cabinet allows up to six I/O and com¬ 
munications controllers and up to five 
5.25-inch peripherals. It also supports 
up to four 5.25-inch disk drives. Main 
memory consists of 8, 16, or 32 Mbytes 
on a board. The system also handles up 
to 64 asynchronous communications 
lines and supports a 60-Mbyte 0.25-inch 
tape drive and an 8 mm helical scan 
magnetic tape subsystem. Available in 
five configurations, the 2850 ranges in 
price from $46,460 to $89,135. 

The EXL 1200 Series is scheduled for 
availability in September. Contact the 
company for more details. 

MBX: Reader Service 35 
2850: Reader Service 36 
1200: Reader Service 37 



Prime Computer’s 2850, which report¬ 
edly hits 2.6 MIPS, joins the 50 Series. 


Workstation, graphics subsystem target CAD market 


Wyse Technology has announced a 
personal workstation and graphics sub¬ 
system that the company says target the 
computer-aided design graphics market. 
The Series 8000 family includes the 
Series 8000CW CAD workstation and 
the Series 8000GS Graphics Subsystem. 


The Series 8000CW consists of the 
25-MHz Wysesystem 386 Model 3225, 
the WY-8400 graphics controller, and 
the WY-890N 19-inch color monitor. 
The Series 8000GS 2D graphics sub¬ 
system can be integrated into existing 
Wyse and other AT-compatible sys¬ 


tems. It consists of the WY-8400 
graphics controller and the WY-890N 
19-inch color monitor. 

The Series 8000 is scheduled for avail¬ 
ability in September. 
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LT-1201 system handles production test 


Tektronix has announced the 
LT-1201, which the company calls a 
semiconductor test system for high- 
volume production testing of small-, 
medium-, and large-scale integration 
logic families. The LT-1201 joins the 
Vista Series of semiconductor test sys¬ 
tems. According to the company, it fea¬ 
tures the series’ modular architecture 
and integrated pin electronics in the test 


Ada for AIX 

Alsys offers an Ada compiler for the 
IBM PS/2 Model 80 under the AIX 
operating system. The AIX Compila¬ 
tion System includes the High-Level 
Optimizer, Binder, Multi-Library Envi¬ 
ronment, Run-Time Executives, 
AdaWorld, and documentation. 

Other features include support for 
bit-level representation clauses and a 
new Low-Level Optimizer. 

Contact the company for pricing. 


head. 

The LT-1201 can be configured with 
two 64-pin test heads, each capable of 
parallel testing. There is one parametric 
measurement unit for each eight I/O 
pins. 

The system features 100-MHz test 
speeds, 16 timing sets, an operating 
voltage range of -2.5V to 7.5V, and 
other specifications identical to those of 


the 256-pin LT-1001 introduced in 
March. The test head weighs 45 pounds. 

The LT-1201 LSI logic test system 
begins at $290,000 for a 32-pin system 
capable of testing two devices simul¬ 
taneously. A typical 64-pin, single-head 
system costs $370,000. The LT-1201 can 
be upgraded to a 256-pin LT-1001. 
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OOSD focuses on object-oriented structured design 


Interactive Development Environ¬ 
ments has announced Object-Oriented 
Structured Design, which the company 
calls a general approach to object- 
oriented design. OOSD reportedly 
depends upon ideas and notation from 
structured design and Booch’s object- 
oriented design, among others. Accord¬ 
ing to the company, the language- 
independent OOSD can be used to 
design for languages such as C + + , 
Ada, Pascal, C, and Fortran. 

The product’s key building blocks are 
modules, classes, and monitors. It 


reportedly synthesizes a top-down func¬ 
tional decomposition approach with a 
bottom-up building block approach. 

IDE is developing a CASE environ¬ 
ment for OOSD, including graphical 
editors, consistency checking functions, 
an object-oriented dictionary, 
documentation-generation facilities, 
code generation for various languages, 
and a reuse library mechanism. 

For more information on OOSD, 
phone (800) 888-IDE1. 
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Oracle adds CASE Generator to its CASE toolset 


Oracle has added the CASE Genera¬ 
tor to its computer-aided systems 
engineering family of application devel¬ 
opment tools. According to the com¬ 
pany, CASE Generator automatically 
generates portable applications directly 
from design specifications. 

CASE Generator receives definitions 
about an application’s database tables 


and program module definitions from 
CASE Dictionary and translates the 
information into functional applica¬ 
tions using SQL Forms, the company’s 
fourth-generation development tool. 
The resulting applications reportedly 
enforce all constraints and validation 
criteria in CASE Dictionary. They sup¬ 
port lists of valid values, help and hint 


text, and automatic synchronization of 
data from multiple database tables. 

Production is scheduled for July, 
with implementations for MS-DOS, 
VAX/VMS, and Sun Unix. Pricing 
varies according to the platform and 
number of users. 


CASE toolset targets real-time cross development 


Wang enhances Windows 


Multiprocessor Toolsmiths offers 
CASEworks/RT, which the company 
calls an integrated software engineering 
solution for cross development of 
multiple-processor real-time and 
embedded systems. The product 
includes software engineering tools for 
design, coding, integration, testing, and 
maintenance, according to the company. 

CASEworks/RT reportedly features 
upgradeable components, modular 
expansion from MS-DOS through Unix 
to VAX/VMS systems, and target- 
portable software. 

CASEworks/RT includes Frame- 


Tool manages behavioral data 

TSSI’s WaveMaker reportedly cre¬ 
ates, captures, and manages behavioral 
and functional data generated in simu¬ 
lation for use throughout the develop¬ 
ment process. The company calls the 
product a natural extension of the TDS 
system. 

WaveMaker consists of four graphi¬ 
cal editors to the TDS waveform data¬ 
base. The editors allow creation and 
modification of signal definitions, 
device timing, data patterns, and full 


work, Copycat, Remedy, and Unison. 
Framework is a Buhrogram-based 
requirements specification and design 
environment. Copycat is a real-time 
operating system simulator. Remedy is 
a C language cross-development debug¬ 
ger that supports multiple communica¬ 
tions channels and real-time 
multiprocessor and distributed proces¬ 
sor development and maintenance. Uni¬ 
son is a real-time operating system. 

Contact the company for more infor¬ 
mation and pricing. 
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in simulation 

composite waveform displays. The 
views of the database can be shown in 
different windows on the workstation 
screen. A change in one editor affects 
the appropriate displays in other editor 
windows, says the company. 

WaveMaker is available on Sun and 
Apollo workstations for $20,000. Cur¬ 
rent TDS users can upgrade to include 
the product. 
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Tool analyzes logic for e-beam probing systems 


Schlumberger Technologies, ATE 
Division, has announced the Logic 
Analyzer Tool, which works with the 
company’s IDS 4000/5000 integrated 
electron-beam probing systems. 
According to the company, the new tool 
overcomes extended test-pattern length 
and repetition-rate limitations. 

Logic Analyzer Tool reportedly pro¬ 
vides the e-beam probing system user 
with the ability to diagnose chips with 
test patterns up to two orders of magni¬ 


tude longer than previously possible; 
increased data-acquisition speeds; inter¬ 
active manipulation of large volumes of 
data; and the ability to diagnose ICs 
with intermittent failures. 

Logic Analyzer Tool can be pur¬ 
chased with IDS 5000 and 4000 e-beam 
probing systems for $45,000, or 
retrofitted onto existing systems for 
$50,000. It is scheduled for October. 


Wang Laboratories has announced 
ClearView, a PC software product that 
the company says enhances and extends 
the use of Microsoft Windows. The new 
software reportedly gives end users 
tools to organize, control, and cus¬ 
tomize the Windows operating envi¬ 
ronment. 

ClearView is a Windows application 
manager with a graphical icon-based 
menu interface and an Organizer utility. 
A List feature within the Organizer 
automates routine functions, according 
to the company. 

ClearView runs on the Wang PC 
200/300 Series, the IBM PC AT and PC 
XT286 and compatibles, and the IBM 
PS/2. ClearView is licensed for $79. 
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S/W verifies IC performance 

Valid Logic Systems claims that its 
TimeView graphical simulation environ¬ 
ment increases productivity during pre- 
and post-layout performance verifica¬ 
tion of integrated circuit designs. The 
product is integrated with the com¬ 
pany’s TimeMill digital IC timing simu¬ 
lator, which performs transistor 
switch-level performance verification. 

Users of TimeView can reportedly 
create stimuli, view output results, and 
manage the overall simulation process. 

TimeView runs on the Sun 
Microsystems Sun-3 and Sun-4 worksta¬ 
tions and Digital Equipment VAXsta- 
tions and DECstations. TimeMill +, 
which includes TimeView and 
TimeMill, costs $35,000. Existing 
TimeMill users can purchase TimeView 
for $7,500. 
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1C Announcements 


Company, Model, Function 


Burr-Brown 
ADS807, ADS808 
ADCs 


Burr-Brown 

ADC700 

ADC 


Gould 

22CV10, 20CG10 
PLDs 


Hitachi America 

HM62832 

SRAM 


Inmos 
IMS T425 
Transputer 


Integrated Digital 

Products 

10486 

Microprocessor 

National Semiconductor 
Super-Block family 
Analog ICs 


Precision Monolithics 
DAC-8228, DAC-8229 
DACs 


Signetics 

PLC42VA12 

PLD 


Syntonic Systems 
Dendros-1 

Neural network chip 


Texas Instruments 
SN74ACT8867GA 
Math coprocessor 


Weitek 
Abacus 4167 
Math coprocessor 


Comments R.s. No. 


Two 12-bit, 100-kHz sampling A/D converters, including an internal sample/hold, 10V refer- 120 
ence, clock, and 8-, 12-, and 16-bit microprocessor-interface circuitry. ADS807 accepts ±5V 
bipolar inputs; ADS808, ±10V bipolar inputs. Come in 28-pin ceramic DIPs. Cost (100s): 
start at $56. 

A 16-bit A/D converter with laser-trimmed reference, clock, and 8-bit port microprocessor 121 
interface. Features 16-bit resolution, 17 ps conversion time, and +0.003% FSR max linearity 
error. Output in serial or parallel form. Comes in a 28-pin ceramic DIP. Cost (100s): from $74. 

Two 24-pin CMOS programmable electrically erasable logic devices. Operate at 25 ns and 122 
consume 55 mA and 45 mA, respectively, in standby mode. Emulate most 24-pin bipolar 
PLDs. Come in 300-mil DIPs. Cost (1,000s): $7 for 22CV10; $4.50 for 20CG10. 

A 256-Kbit static RAM in a 330-mil skinny DIP. Organized 32 Kbits x 8 bits. Can access 8 123 

bits of data in 35 ns. Has standby power of 10 pW. Jointly developed with VLSI. Now sam¬ 
pling, with production in the third quarter. Cost (1,000s): for 35-ns chip, $68 for plastic DIP 
or $72 for plastic J-lead. 

A pin-compatible upgrade for the IMS T414. Integrates a 12.5-MIPS 32-bit microprocessor, 124 
four serial links running at 2.4 Mbytes/s, 4 Kbytes of SRAM, and a 32-bit memory chip. 

Adds a refresh pending pin and an event waiting pin. Comes in an 84-pin PGA with three 
speed options. Cost (100s): $269 (20 MHz). 

A 90-MHz, 32-bit, 30-MIPS microprocessor with a 33-ns cycle time, on-chip memory map- 125 
ping, direct support for up to 1 Mbyte of memory, dual data buses, ECL internal logic, and 
TTL I/O. Comes in a 149-pin PGA. Available in Mil-Std-883C versions. Classes B and S. 

Cost (1,000s): $895. 


A family of analog ICs. First members are the LM604 four-channel multiplexer-amplifier, 126 
LM611 single-supply op amp, LM613 dual op amp and dual comparator, and LM614 quad 
op amp. Cost (100s): $2.30 for LM604 (18-pin plastic DIP); $0.84 for LM611 (8-pin plastic 
DIP); $1.30 for LM613 (16-pin plastic DIP); $1.22 for LM614 (16-pin plastic DIP). 

Dual 8-bit voltage output CMOS D/A converters. DAC-8228 handles single-supply opera- 127 
tion. Features two internal amplifiers. DAC-8229 operates with dual supplies. Both come in 
plastic and ceramic DIPs in extended industrial temperature range. Cost (100s): start at $3.95 
for plastic DIP. 

A programmable logic device that integrates the architectures of the 22V10 and 20RA10. 128 

Has both synchronous and asynchronous clocking. Provides 105 product terms for control 
and logic in two programmable arrays. Has 10 programmable output macro cells and two 
bidirectional I/O channels. Cost (1,000s): $10. 

A neural network chip that implements 22 synapses and includes circuitry for dynamic modi- 129 
fication of synaptic weights (stored in off-chip capacitors). Uses analog computation to do 
the equivalent of 4.3 Mflops. Does parallel dot-product calculation. Comes in a 68-pin 
PLCC. Cost: $35 ($695 for evaluation board). 

A 32-bit vector processor that combines an independently operated multiplier and arithmetic 130 
logic unit with a 46-word x 40-bit register file. Supports 40-bit floating-point arithmetic and 
32- or 64-bit fixed-point arithmetic. Made using TI’s 1-micron EPIC CMOS process. Comes 
in a 208-pin PGA. Cost (1,000s): $500. 

A floating-point coprocessor for the Intel 80486 microprocessor. Plugs into a socket on the 131 
system board. Compatible with existing Abacus 3167 applications for 386-based machines. 

Has a memory-mapped protocol and 16 64-bit data registers. Sampling in September. Cost 
(1,000s): $565. 


106 


COMPUTER 








Microsystem Announcements 


Company, Model, Function 

Comments R.S. No. 

American Megatrends 

386 AT/33 

Motherboard 

A motherboard based on a 33-MHz 80386 CPU. Has a Landmark (version 0.99) rating of 135 

55.9 MHz. Features an on-board cache controller with 64 Kbytes of 20-ns static RAM, which 

buffers up to 16 Mbytes of 60-ns dynamic RAM with zero wait state. Cost: $3,995. i 


Avalon Computer Systems A RISC-based application accelerator for DEC VAX and MicroVAX systems. Requires no 136 
Vaccelerator AP/30 user reprogramming. Hits 15-20 VAX MIPS. Can be configured in parallel and operated con- 


Accelerator 

currently, up to 10 boards. Cost: $15,900 with 4 Mbytes of memory. j! 

; DSP Systems 

Analog-to-digital converter board with up to a 20 megasamples/s digitizing rate and either 12 137 


ADC12/20M, ADC10/20M or 10 bits accuracy. Uses a daughter board ADC modules mounted on the reverse side of 


A/D converter board 

VME 6U compatible motherboard. Cost: $4,995 for ADC10/20M; $9,499 for ADC12/20M. 

Force Computers 

CPU-31 

SBC 

A 32-bit single-board computer based on Motorola’s 68030 CPU and 68882 math coproces- 138 
sor. Uses synchronized dual-ported static RAM. Employs a high-density application-specific i 

gate array that implements a message-passing architecture. Comes with VMEPROM. Cost: i 

$9,490 for 16.7-MHz CPU-3IX; $9,790 for 20-MHz CPU-31XA. 

Force Computers 

DRAM-8 series 

Memory boards 

A family of dynamic RAM VMEbus memory boards with storage ranging from 2 to 32 139 

Mbytes. Use standard 1- or 4-Mbit chips (when available). Currently specified for read ac- i 

cess of 240 ns and write access of 100 ns. Slave boards, with parity, compatible with IEEE- 
1014 spec. Cost: $1,390 (8A, 2 Mbytes); $1,890 (8B, 4 Mbytes); $3,290 (8C, 8 Mbytes). 

Industrial Computer 
Designs 

CSX8-PC 

I/O board 

An eight-channel, RS-232-C, serial I/O board for IBM PC, XT, AT, and PS/2 (Model 30) 140 

computers and compatibles. Has a Z80-based serial coprocessor board, independent setting 
of channels at separate baud rates, and channel operation from 110 to 19.2 Kbaud. Comes ■, 

with DOS drivers and sample software. Cost: $995. 

MetraByte 

MBC-GAD, MBC-DAC 
ADC, DAC boards 

Plug-in daughter boards for the MBC-625 data-acquisition system for Macintosh II and SE 141 

microcomputers. MBC-GAD performs a 16-bit A/D conversion at 16,000 samples/s with ac- * 

curacy of 0.003%. MBC-DAC has two independent, 16-bit, analog output channels and proc- i 

esses at 100,000 samples/s to 0.006% accuracy. Cost: $550 for MBC-GAD; $475 for MBC- ; 

DAC; $1,290 for MBC-625. | 

MetraByte 

DAS-HRES 

* Interface board 

A high-resolution, multifunction analog and digital interface board for IBM PC, XT, AT, and 142 
compatible computers. Features an on-board A/D converter with 16-bit resolution. Comes 

with utility software. Cost: $1,995; $120 for screw terminal board, $30 for cable. : 

MicroWay 

Videoputer 

Graphics board 

A transputer-based graphics board for IBM PC AT and 80386-based computers with at least 143 
one MicroWay Monoputer2 or Quadputer2 installed. Contains one 20- or 25-MHz Inmos » 

T800 transputer, which shares 1 Mbyte of dual-ported video RAM with a TI 34010 graphics 
controller. Comes with graphics libraries and a test program. Cost: $4,995. 

Preston Scientific 

P/DAS Series 

Data acquisition system 

A plug-in data acquisition system with an A/D converter providing either 12-bit or 16-bit 144 

resolution. Model P/DAS-16 operates at a conversion rate of 400 kHz; Model P/DAS-12 op- ‘ 

erates at more than 800 kHz. Features a 1 MHz data transfer rate. Runs on 286- or 386-based 

PCs. Cost: $3,600 for P/DAS-12; $5,500 for P/DAS-16. 

Spectrum Signal 
Processing 

DSP32C System Board 
DSP board 

A PC-based board for development and implementation of floating-point DSP applications 145 

on the IBM PC AT. Consists of an AT plug-in board designed around AT&T’s DSP32C. Has ■; 

two 16-bit A/D and two 16-bit D/A converters, DSP-Link system expansion interface, and 

parallel and serial data communications. Cost: $2,995. !< 

Terametrix Systems 
International 

Micro-TLM 
Decommutation system 

A hardware and software decommutation system for processing pulse code modulation te- 146 -) 

lemetry data. Consists of three circuit boards, a bit synchronizer/decoder and IRIG-B time 

code reader, decommutator, and 16-channel D/A converter. Fits an IBM PC AT compatible. i 

Cost: starts at $15,000 ($24,000 for workstation). 

Themis Computer 
TSVME-123 

SBC 

A VMEbus single-board computer based on a 16-MHz 68020 microprocessor. Features 256- 147 ' 

512 Kbytes of local zero wait-sate RAM, 1 Mbyte of shared memory, triple-bus DMA archi¬ 
tecture, and custom application module interconnect with two access ports to shared mem¬ 
ory. On-board self-test and debug monitor. Cost: $3,695. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...up to 5 years 
experience...,” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


McGill university 
SCHOOL OF COMPUTER SCIENCE 

Applications are invited for a tenure-track 
position at the Assistant or Associate Pro¬ 
fessor level in the School of Computer Sci¬ 
ence. Those candidates with an established 
record in the systems area such as software 
engineering, programming languages, data 
bases, architecture and distributed systems, 
will be given first priority. The School has 
fifteen Professors, and a network of UNIX- 
based SUN computers. We have a large 
graduate program with over 100 students. 
Interested individuals should write to: 
Professor Renato De Mori, Director 
School of Computer Science 
McGill University 
McConnell Engineering Building 
Room 318 

3480 University Street 
Montreal Quebec H3A 2A7 
Canada 

Canadian Immigration Laws require us to 
give priority to Canadian citizens or Landed 
Immigrants. 


DIANETICS 

How can you realize your mind’s poten¬ 
tial? Discover and use Dianetics,® the totally 
practical science of the mind, by bestselling 
author L. Ron Hubbard. Order your copy 
today. Call now: 1-800-367-8788. Hard¬ 
back $25.00. Dianetics is a registered 
trademark. 


TULANE UNIVERSITY 

The Department of Electrical Engineering 
at Tulane University has an immediate open¬ 
ing for a full-time, tenure track faculty posi¬ 
tion. Duties include teaching graduate and 
undergraduate courses, research, and advis¬ 
ing students. Rank and salary are commen¬ 
surate with qualifications. Requirements: 
Doctorate or final stages of completion of a 
doctorate in Electrical or Computer Engi¬ 
neering. Complete vitae with a minimum of 
three references should be sent as soon as 
possible to Dr. S. T. Hsieh, Department of 
Electrical Engineering, Tulane University, 
New Orleans, LA 70118-5674, (504) 865- 
5785. All candidates should indicate citizen¬ 
ship and, in the case of non-US citizens, 
describe their visa status. Tulane University is 
an equal opportunity/affirmative action 
employer. 


UNIVERSITY OF SOUTHERN 
CALIFORNIA 

Post Doctoral Research Position 

Electrical Engineering Department, Uni¬ 
versity of Southern California. Temporary 
full time position for two years commencing 
in September 1989, with possibility of exten¬ 
sion contingent upon funding. Salary 
$44,000 to $50,000 per annum, dependent 
on qualifications. Assist in development of 
knowledge based system for design of test¬ 
able digital systems. Ph.D. degree in CS or 
Computer Engineering, research experience 
in VLSI design, testing and design for test, 
and a strong background in software engi¬ 
neering. Send resume to Professor M.A. 
Breuer, Electrical Engineering-Systems De¬ 
partment, University of Southern California, 
Los Angeles, CA 90089-0781. USC is an 
equal opportunity, affirmative action 
employer. 


UNIVERSITY OF WISCONSIN- 
MADISON 

Phillip Dunham Reed Chair 
in Electrical & Computer Engineering 

The University of Wisconsin-Madison in¬ 
vites applications and nominations for the 
Endowed Phillip Dunham Reed Chair in 
Electrical and Computer Engineering. An 
applicant or nominee should be an interna¬ 
tionally recognized scientist or engineer, 
holding a Ph. D. degree or equivalent in elec¬ 
trical engineering, computer engineering, or 
a related field. 

Applications or nominations should be 
sent to: Professor J. Leon Shohet, Chair¬ 
man, Department of Electrical and Com¬ 
puter Engineering, University of Wisconsin- 
Madison, Madison, Wisconsin 53706. The 
University of Wisconsin-Madison is an equal 
opportunity/affirmative action employer. 


DATA COMPRESSION & IMAGE 
ANALYSIS SPECIALIST 

The Universities Space Research Associa¬ 
tion (USRA) is currently seeking a computer 
scientist/engineer to conduct research and 
analysis on lossy and lossless data compres¬ 
sion approaches for high volume satellite 
image data. The individual will be heading 
the Algorithms and Applications subtask of 
the Configurable High Rate Processor 
System (CHRPS), in the Space Data and 
Computing Division at the Goddard Space 
Flight Center. 

The objective of the research activity will 
be to study various lossy and lossless data 
compression approaches and develop one 
or a few that most efficiently preserve satellite 
data images. Candidates should have a 
Ph.D. in computer science/engineering, 
and three years experience in image data 
compression or multispectrai earth observa¬ 
tion image analysis. Experience in massively 
parallel (SIMD) algorithm design is highly 
desirable. The appointment will be for one 
year, renewable subject to performance and 
continued funding. Salary will be com¬ 
petitive, commensurate with experience. 

The Universities Space Research Associa¬ 
tion is a non-profit university consortium, 
chartered to foster cooperation between 
universities and the U.S. Government 
toward the advancement of research and 
education in space science and technology. 
USRA is an equal opportunity employer. 
Applications received before August 1 will 
receive full consideration. Send curriculum 
vitae and contacts for references to: 

David Holdridge 

USRA Visiting Scientist Program 

Code 610.3 

NASA Goddard Space Flight Center 
Greenbelt, MD 20771 
(301) 286-5057 


TRINITY COLLEGE 
Computer Science 

Applications are invited for a tenure track 
position in Computer Science in the Depart¬ 
ment of Engineering and Computer Science 
at Trinity College starting in January 1990. 
The position involves undergraduate and 
graduate instruction and research. A doc¬ 
toral degree in Computer Science or equiva¬ 
lent is required. Applicants will be con¬ 
sidered in all areas of computer science that 
complement or strengthen our current cur¬ 
ricular/research programs. We are inter¬ 
ested in receiving applications from qualified 
women and minorities. Trinity College is an 
equal opportunity/affirmative action em¬ 
ployer. Please send resume to Professor 
Joseph D. Bronzino, Chairman, ECS De¬ 
partment, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin on May 1, 1989 and the search will re¬ 
main open until the position is filled. 
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COMPUTER AIDED ENGINEERING 
(CAE) AND PROCESSING SCIENTIST 

Computer Aided Engineering (CAE) and 
Processing Scientist for manufacturer in cen¬ 
tral Ohio needed for application and 
development of Computer Aided Engineer¬ 
ing (CAE) software for analysis of metal 
working problems. Use Finite Element 
Method (FEM) analysis to simulate metal 
forming process like extrusion and forging, 
from mesh generation through post-proces¬ 
sing of the results. Develop new and make 
enhancements to existing software packages 
for pre and post processing of FEM results. 
Develop software tools to assist in the com¬ 
puter aided design and manufacture of ex¬ 
trusion dies. Must have M.S. Degree in 
Mechanical or Metallurgical Engineering. 
Graduate level courses must include: Finite 
Element Methods (FEM), Computer-Aided 
Design (CAD), Advanced Numerical 
Methods and Computer Integrated Manu¬ 
facturing. Must have course work or research 
during degree program in FEM analysis to 
simulate metal forming processes like extrus- 
tion and forging. Must have coursework of 
thesis work or research in CAD systems, pro¬ 
gramming in FORTRAN under VAX/VMS 
operating systems, using callable graphics 
libraries, and developing post-processors for 
FEM data base. 40 hrs/wk, 8:30 a.m.-5:30 
p.m. $32,000 per year. Qualified applicants 
send resume (NO CALLS) to C. Bussard, 
JO* 1197509, Ohio Bureau of Employment 
Services, P.O. Box 1618, Columbus, Ohio 
43216. 

An equal opportunity, affirmative action 
employer. 


UNIVERSITY OF 
COLORADO / BOULDER 

The Department of Electrical and Com¬ 
puter Engineering is seeking a quality tenure- 
track faculty member to further enhance its 
research and educational activities in Com¬ 
puter Engineering. The successful candidate 
must have an outstanding academic record 
and significant achievement in original re¬ 
search as well as interest in undergraduate 
and graduate education. A Ph.D. degree in 
Electrical Engineering, Computer Engineer¬ 
ing, Computer Science or other related field 
is required; salary will be commensurate with 
qualifications and experience. Preference 
will be given to candidates at the Assistant 
Professor level but candidates at all levels will 
be considered. Areas of specialization in¬ 
clude, but are not necessarily limited to, Soft¬ 
ware Engineering, Programming Languages, 
Operating Systems, Hard ware/Software In¬ 
terface and Computer Architecture. 

The University of Colorado at Boulder has 
a strong institutional commitment to the prin¬ 
ciple of diversity in all areas. In that spirit, we 
are particularly interested in receiving appli¬ 
cations from a broad spectrum of people, in¬ 
cluding women, members of ethnic minori¬ 
ties and disabled individuals. 

Applications for this position should be 
sent to: Prof. Frank S. Barnes, Dept, of Elec¬ 
trical and Computer Engineering, University 
of Colorado, Campus Box 425, Boulder, 
CO 80309-0425. Deadline for application is 
September 30, 1989. 


CENTRAL CONNECTICUT 
STATE UNIVERSITY 

COMPUTER INTEGRATED MANU¬ 
FACTURING-Coordinator of CIM 
Laboratory. Assists Chairperson of Com¬ 
puter Applications Laboratory in the ad¬ 
ministration of the Computer Integrated 
Systems Laboratory. Bachelor’s degree in 
appropriate field and demonstrated knowl¬ 
edge of and experience and skill in computer 
integrated systems, computer assisted design 
and computer assisted manufacturing re¬ 
quired. Industrial experience, experience 
working with DEC Vax, McDonnel Douglas 
and Intergraph systems, and skill in pro¬ 
gramming in Fortran and Pascal preferred. 
Send letter of application and resume with 
names, addresses and telephone numbers of 
three references to Dr. Paul J. Resetarets, 
Chair, Computer Applications Lab, School 
of Technology, CENTRAL CONNECTI¬ 
CUT STATE UNIVERSITY, New Britain, 
CT 06050-4010 by September 1, 1989. 
CCSU is an AA/EO employer. Women, mi¬ 
norities, handicapped, and veterans are en¬ 
couraged to apply. 


SYSTEMS ANALYST 

Minimum 1 year experience with BS 
degree either computer, systems or related 
field or will accept entry level with MS degree 
above fields. Will set up and implement com¬ 
puter programs and procedures in connec¬ 
tion with our financial auto loans, vehicle 
maintenance programs, customer relations 
and communications between branch of¬ 
fices. Will analyze data and put into proper 
format including accounting and financial 
functions, budget forcasting reports and cost 
accounting. Salary $38,800 year; Please 
send resume to: G.G. International Motors, 
Inc., 8722 Garden Grove Blvd., Garden 
Grove, CA 92644, Attn: Howard Kim, 
President. 


ViGYAN INC. 

Hampton, Virginia 

Applications are invited from candidates 
with either an MS or a Ph D. in Computer 
Science or Mathematics for the following 
positions available immediately. 

1) Research in mathematical logic, formal 
specification languages and formal verifica¬ 
tion methodologies, digital logic, and com¬ 
puter system architectures. 

2) Research related to development of 
knowledge-based expert systems and soft¬ 
ware engineering techniques and related 
system development environments or 
“shells”. 

ViGYAN is a progressive R&D company 
and offers competitive salaries with excellent 
benefits package. Please send resume to: 
Barbara Kraft at 30 Research Drive, Hamp¬ 
ton, VA 23666-1325. 


THE GEORGE WASHINGTON 
UNIVERSITY 
Research Positions 
School of Engineering and 
Applied Science 

Research positions at junior and senior 
ranks, both faculty and staff, are available in 
specialty areas that include, but are not 
limited to, the following: 

• Artificial Intelligence and Expert Systems 

• Communications 

• Computer-Aided Systems and Software 
Engineering 

• Computer-Integrated Manufacturing 

• Computational Fluids and Solids 

• Computer Science 

• Environmental Engineering 

• Failure of Materials and Structures 

• Information Management 

• Reliability 

• Robotics 

• Superconductivity 

Applicants should have a demonstrated 
history in securing sponsored research fund¬ 
ing and the ability to interact with faculty, 
research staff and students in support of the 
School’s academic programs. Candidates 
with earned degrees in engineering or 
science are desirable. Applications will be 
reviewed bi-monthly and appointments 
made throughout the year. Salary and rank 
will be commensurate with education, ex¬ 
perience, and qualifications. 

Applicants should send vita, including 
complete publication list, research support 
summary, and three references to: 

School Administrator 
School of Engineering and Applied Science 
The George Washington University 
Washington, D.C. 20052 
Equal Opportunity/Affirmative Action 
Employer. 


UTAH SUPERCOMPUTING INSTITUTE 

The University of Utah Supercomputing 
Institute invites applications for three staff 
positions in the areas of (i) graphics, 
visualization and animation, (ii) scientific 
computing, and (iii) development and im¬ 
plementation of parallel algorithms. Prefer¬ 
ence will be given to applicants with a Ph.D. 
in Applied Mathematics or Computer 
Science, but applicants with a degree in 
other areas of science or engineering will be 
considered. 

The objectives of the institute are to pur¬ 
sue research and development in the above 
areas and to provide services in these areas 
to the faculty via consulting and courses. 
Staff members will be expected to pursue 
research in their area of expertise. Adjunct 
appointments in academic departments will 
be considered. 

To apply send a curriculum vita to Prof. 
Hans. G. Othmer, Dir. of Academic Super¬ 
computing, Dept, of Mathematics, Universi¬ 
ty of Utah, Salt Lake City, UT, 84112 and 
arrange to have three letters of recommen¬ 
dation sent to this address. The University of 
Utah is an affirmative action/equal oppor¬ 
tunity employer. 
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Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; Compmail, e.gallizzi 


ICSE 11 prompts engineers to reflect on yesterday, look to tomorrow 

Frost McLaughlin, Carnegie Mellon University 


Don’t reflect too long on yesterday 
because technology is moving very 
rapidly toward tomorrow. That was the 
advice conference chair Larry Druffel 
of the Software Engineering Institute at 
Carnegie Mellon University gave when 
he welcomed attendees at the opening 
plenary session of the 11th Interna¬ 
tional Conference on Software 
Engineering, held in Pittsburgh May 
15-18. 

In his remarks, Druffel recommended 


that the participants pause and look 
back only long enough to understand 
the profession from an historical per¬ 
spective, but then to continue looking 
forward because of the speed at which 
technology is progressing. 

“Twenty Years of Software 
Engineering: Looking Forward, Look¬ 
ing Back” was the theme of ICSE 11, 
which drew more than 1,000 persons 
from 20 countries. Richard Fairley of 
George Mason University and Dines 


Bjorner of the Dansk Datamatik Center 
served as program co-chairs of the con¬ 
ference, sponsored by the IEEE Com¬ 
puter Society Technical Committee on 
Software Engineering, the ACM Special 
Interest Group on Software Engineer¬ 
ing, and several other international 
organizations. 

Plenary speakers. In his plenary 
speech, John Buxton of the University 
of London said that, while the term 
“software engineering” may have 
emerged in other geographical locations 
simultaneously, its use was legitimized 
at the 1968 NATO workshop in Gar- 
misch, Germany. Software engineering 
and the problems its practitioners were 
experiencing formed the central topic of 
that workshop. 

Buxton, who was responsible for the 
preparation of requirements for Ada 
programming support environments 
(APSEs) and the principal author of the 
US Department of Defense Stoneman 
report, was a member of the organizing 
committees for both the 1968 and 1969 
NATO workshops. 

In retrospect, several speakers at 
ICSE 11 who had attended those early 
NATO workshops mentioned issues 
that are controversial within the soft¬ 
ware engineering profession today. 
Recalling the background of the work¬ 
shop 20 years ago, Buxton said there 
was a “software crisis” in which soft¬ 
ware was late, over budget, and full of 
errors. The paradigm proposed at the 
workshop for solving those software 
problems was to investigate the analogy 
between software and other engineering 
disciplines. 

Members of the workshop agreed to 
meet in Rome the following year, by 
which time, Buxton confided, many felt 
that the problems causing the “crisis” 
would be solved. The fact that some of 
the same problems are evident today 
was reflected in many sessions at ICSE 

The second plenary speaker, David 
Gries of Cornell University (author of 
The Science of Programming and other 
computer science texts), was also a par- 


Developer trends detected during programmer 
‘bake-offs’ reported at ICSE 11 

Galen Gruman, Staff Editor, IEEE Software 


To gauge the state of the practice, 
Tom DeMarco and Tim Lister, consul¬ 
tants and software-development 
book writers, have run a series of pro¬ 
gram “bake-offs” where two-person 
programmer teams are given the 
same specification and problem to 
solve in their choice of language. 

One partner would try to find as 
many bugs as possible in the other’s 
work; the person who wrote the code 
had no opportunity to fix any errors. 

The contests took place from late 
1984 through 1988. DeMarco and 
Lister presented their results in May 
during the 11th International Confer¬ 
ence on Software Engineering in 
Pittsburgh. 

While they admit their contest was 
not a controlled, scientific study, 
DeMarco and Lister found some 
trends they believe apply to most 
developers: 

• Most programmers used mod¬ 
ules of less than one page in length. 
The use of shorter modules cor¬ 
related to faster execution speed. 
There is less payback for modularity 
in small programs, but because the 
programmers modularized their code 
even in these small programs, 
DeMarco said he felt this showed 
that “small modules are the basic 
approach used today.” 

• About half the programmers tried 


to modularize their data so it was 
visible only in the module that 
defined it. Programs that empha¬ 
sized locality tended to outperform 
the others. 

• Most programmers had strong 
cohesion, encapsulating their 
algorithms in modules. 

• About a third built programs with 
no errors. The programs’ average 
length was 163 Pascal lines or 230 
Cobol lines. Considering that most 
people were novices to the clean- 
room approach of doing it right the 
first time, the results were “pretty 
exciting,” DeMarco said. 

• Structured programming was the 
norm. However, “structured” means 
not goto-less but sensible structured 
programming constructs, DeMarco 
said. 

• One company that enforces a 
“right way” of program design had 16 
programmers participate. Did the 16 
programmers’ code match each 
other? “No way!” Lister said. Overall, 
DeMarco and Lister saw a 3:1 varia¬ 
tion in length for the code even 
though the programmers were solv¬ 
ing the same problem in the same 
language based on the same specifi¬ 
cations. “This is worrisome for those 
who encourage lines of code as a 
productivity measure,” DeMarco 
said. 
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ticipant at the NATO workshops. Gries 
spoke about the need for disciplined 
and rigorous precision in computer 
science education and advocated teach¬ 
ing (and using) formal methods, calling 
the time required to learn and use for¬ 
mal methods a worthwhile 
“investment.” 

Speaking at a session entitled “Soft¬ 
ware Engineering in the Year 2001 
Michel Sinztoff of the Catholic Univer¬ 
sity of Louvain in Belgium voiced a 
similar desire for rigor and technical 
precision, which he defined as slightly 
different from the concept of “correct¬ 
ness.” The tolerance for errors in soft¬ 
ware and the general lack of 
mathematical control over software 
development was echoed in several ses¬ 
sions of the conference. 

Software measurement was men¬ 
tioned in a panel titled “Software 
Engineering Research Agendas: A View 
From the Trenches.” Panelist Ilene 
Birkwood of Tandem Computer sum¬ 
marized a list of software development 
activities over which she would like to 
have stricter management control, say¬ 
ing “we have tons of data, but no usa¬ 
ble information.” A general consensus 
of that and other panels seemed to be 
that research should provide the much- 
needed metrics for software mea¬ 
surement. 

Other suggestions for research 
agendas were: to be more effective, 
researchers need to acquire expertise in 
a specific application domain; large, 
complex software artifacts would pro¬ 
vide useful research; the traditional 
handbooks of engineering, absent in the 
realm of software, would be extremely 
helpful in the field; and a new, impor¬ 
tant realm for research exists in the area 
of technology transition—the “bridge 
builders,” in the words of MCC’s Les 
Belady, between academe and industry. 

Other current issues remembered as 
topics in the 1968-69 NATO workshops 
included reuse, or Doug Mcllroy’s early 
notion of reusable software components 
(not, several participants pointed out, 
exactly the concept of a “software fac¬ 
tory” that is often attributed to him). 
When queried about the effectiveness of 
reuse in general, Buxton said he is 
“dubious” about reuse below the 
design level, except in areas of narrow 
application like mission-critical systems. 

The human component of software 
engineering, a frequent topic at the con¬ 
ference, was the focus of a plenary 
speech by Bill Curtis, director of the 
MCC Technology Program. Curtis 
presented some results of his research 
on design methodologies, computer- 
aided collaborative design, and design 
behavior. In a speech entitled “What 


You Have to Understand: This Isn’t the 
Way We Develop Software at Our 
Company,” Curtis maintained that a 
problem with process models is that 
they assume certain human behavior 
that may or may not be the case. 

Focus on CASE tools. CASE tools 
were discussed at length in several ses¬ 
sions. One panelist remarked that con¬ 
figuration management in the 1960s 
amounted to “rubber bands” and 
“cardboard boxes.” Alan Kay, an 
Apple Computer fellow, likened CASE 
tools to “an orthotic brace for the 
hopelessly crippled.” However, when 
members of the panel titled “A View 
from the Trenches” were queried about 
their experience using CASE tools, 
most gave qualified affirmation that 
they are helpful. Meanwhile, CASE 
tools were presented in the concurrent 
tools presentation track, as well as in 
the tools exhibition. 

Despite some of the same 1960s issues 
being prevalent today, Buxton summed 
up the past 20 years of software 
engineering as involving “remarkable 
progress.” He mentioned life-cycle 
models, chief program teams, and qual¬ 
ity assurance as effective management 


ideas that have evolved during that 
time, and methods and tool sets as tech¬ 
nological advances. In his view of 
tomorrow, Buxton predicted that 
“bridging the gap to the user domain” 
will be the next major breakthrough. 

“We’ve made some spectacular 
steps,” said Buxton, adding that our 
technical advance has been “restricted 
to the algorithmic” and that “most 
people don’t think in algorithms.” 

In the session on “Software 
Engineering in the Year 2001,” panelist 
Bob Balzer of the University of South¬ 
ern California Information Sciences 
Institute mentioned extensible user 
interfaces as a future item, while 
another panelist, consultant Michael 
Jackson, countered that “dedicated 
hardware” will likely negate the chal¬ 
lenge for extensible user interfaces. In 
his plenary talk, Curtis listed reuse tech¬ 
nology, better design technology, a pro¬ 
totyping platform, coordination 
technology, and empirical studies as 
items to be pursued as soon as 
plausible. 

Alan Kay, generally acknowledged as 
the father of the personal computing 
concept with his Dynabook (predeces¬ 
sor of the Apple Macintosh), discussed 


Software reliability session at ICSE 11 
draws overflow crowd 


Although not on the advance pro¬ 
gram for the 11th International Con¬ 
ference on Software Engineering in 
Pittsburgh May 15-18, a “birds of a 
feather" session on applications of 
software reliability measurement 
nevertheless drew an overflow crowd, 
symptomatic of the explosively grow¬ 
ing interest in this area. 

John Musa of AT&T Bell Laborato¬ 
ries gave an overview of software 
reliability measurement technology. 
Musa pointed out that software relia¬ 
bility is the most important aspect of 
software quality. He outlined applica¬ 
tions in system engineering, test, 
and operation, and in evaluating the 
impact of software engineering tech¬ 
nologies. 

The Jet Propulsion Laboratory 
plans to use software reliability mea¬ 
surement in some of its deep space 
projects. Michael Lyu of JPL noted 
that counts of faults uncovered yield 
only rough approximations of soft¬ 
ware quality. Hence, the movement 
toward software reliability, a very sig¬ 
nificant issue for deep space flight. 

Sam Keene of IBM in Boulder, 
Colorado, discussed the importance 


of software reliability with relation to 
the US Department of Defense Criti¬ 
cal Technologies Plan. He noted that 
quality metric monitoring was a key 
step in enhancing software produc¬ 
tivity. High levels of maturity of the 
software development process (as 
characterized by the Software 
Engineering Institute) require good 
measurement of that process. 

The final talk described 
experiences with application of soft¬ 
ware reliability measurement to a 
telecommunications traffic measure¬ 
ment system. Pat Kennihan of AT&T 
Network Systems discussed the 
development of a tool for measuring 
the processor execution time 
between failures. The initial version 
added too much overhead and 
affected system performance. After 
focusing on this issue, a version with 
greatly improved (and satisfactory) 
performance was developed. Kenni¬ 
han noted the utility of automatically 
detecting as many failures as possi¬ 
ble. He recommended that a failure 
intensity (failures per thousand 
hours of execution) objective be 
specified for every software product. 
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Table I. Scenario for software of yesterday, today, and tomorrow. 



Yesterday 

Today 

Tomorrow 

Where 

Machine room 

Desktop 

Wherever you are 

Who 

Expert 

Individuals 

Collaborative groups 

What 

Edit 

Lay out 

Orchestrate 

How 

Remember and type 

See and point 

Ask and tell 

Desired 

Response time 

MIPS 

Accountability 

Size 

1.6 million 
lines of code 

150,000 lines of code 

1,500 lines of code 

Power 

.05-. 1 MIPS/user 

1-4 MIPS/user 

50-100 MIPS/user 

Style 

Data/procedures 

Object-oriented 

Rules 

Operation Mode 

Subservience 

Independence 

Freedom 


the 25-year interval required to get 
powerful new technology to the field, 
quipping that the interval was the time 
required for the proponents of old tech¬ 
nology to die. Kay pointed out that the 


next major breakthrough is in some¬ 
one’s lab right now. In the final plenary 
session, Kay set down the scenario 
detailed in Table 1 for software of 
yesterday, today, and tomorrow. 


Kay concluded with a videotaped 
demonstration of what he called an 
“agent”: a semi-intelligent process that 
does the user’s vocal bidding on tasks 
such as finding and displaying informa¬ 
tion. The chief shortcoming of such an 
agent would be, in Kay’s words, that, 
like with a nice puppy who gets your 
slippers and occasionally has accidents, 
“you would have to protect every¬ 
thing” (files, etc.) from your agent. 

The proceedings, order No. 1941, is 
available from the Computer Society 
Press, Los Alamitos, California, by 
calling (800) CS-BOOKS or (714) 
821-8380 in California. 

ICSE 12 will be held in Nice, France, 
March 26-28, 1990. It will focus on 
efforts in different aspects of software 
engineering—basic research, advanced 
developments, experiences of technol¬ 
ogy transfers, and analyses of empirical 
results—essential to building a solid 
foundation and for anticipating the 
future. 


CompEuro demonstrates support for technical integration of Europe 


Edmund Gallizzi, Eckerd College 

“It is evident, therefore, that the 
European Community needs to develop 
strategies and policies for the future 
development of the [information and 
communication technologies] sector, 
taking into consideration the specifici¬ 
ties and the particularities of the Euro¬ 
pean situation.” 

So said H. Huber of the European 
Community when he delivered one of 
the plenary speeches at CompEuro 89, 
held May 8-12 in Hamburg, West 
Germany. 

The event was cosponsored by the 
IEEE Computer Society, Gesellschaft 
fur Informatik, and Verband Deutscher 
Elektrotechniker. Walter E. Proebster 
of IBM and Winfried Schott of Philips 
were the conference chairs, and Hans 
Reiner of SEL and Kurt Garbrecht of 
Siemens were the technical program 
chairs. The Germany Section of the 
IEEE celebrated its 25th anniversary 
during the conference. 

The technical integration of Europe 
in support of the “Single Europe Act,” 
which will unify many facets of the 
European Community in 1992, was an 
important topic addressed in several 
components of the conference within 
the conference theme, “VLSI and Com¬ 
puter Peripherals.” 

Huber’s plenary presentation and 
paper, “European Cooperation on Inte¬ 
grated Broadband Communication— 


The RACE Programme,” outlined the 
European Community’s program 
“aimed at the creation of the necessary 
conditions for the Europe-wide intro¬ 
duction of IBC (integrated broadband 
communication) services by 1995.” 
RACE, an acronym for Research and 
Development in Advanced Communica¬ 
tions Technologies in Europe, was 
initiated in 1988 and has three aspects: 

(1) Development of a consensus 
among the partners that addresses com¬ 
mon definitions and approaches for 
IBC systems, a framework for future 
research, and mechanisms necessary to 
facilitate the definition of international 
standards; 

(2) Research and development of 
technologies necessary for IBC that 
include networks and switching, optical 
communication, signal processing, 
advanced information processing, and 
customer systems and user interfaces; 

(3) Implementation of pilot projects 
that deal with the major issues of equip¬ 
ment and installation, user access func¬ 
tions, and functional integration and 
IBC characteristics. 

Broadband communication. “Broad¬ 
band communication is already a real¬ 
ity,” according to Horst Ohnsorge of 
SEL/Alcatel, who outlined the status 
and future Of IBC in his plenary presen¬ 
tation and paper, “Broadband 


Communication—The Key to Advanced 
Terminals.” Currently, broadband 
communication is available in Ger¬ 
many, the first country to provide the 
service. Broadband communication 
connects 29 cities with optical fiber sub¬ 
scriber lines connected to a fiber optic 
backbone. It has been a switched self¬ 
dial network since 1988. 

Another system in Germany is Ber- 
kom, the first Broadband Integrated 
Services Digital Network (B-ISDN) 
under the operation of PTT administra¬ 
tion with public subscribers. This sys¬ 
tem, which will be extended to operate 
with both synchronous transfer modes 
(STM) and asynchronous transfer 
modes (ATM), is a testbed for all ser¬ 
vices, including telephone, data, dialog 
video services, and television and radio 
program distribution. It will become a 
component of a Europe-wide IBC net¬ 
work in the third part of the RACE 
program. 

To provide “broadband services for 
everybody,” the cost and performance 
of the basic system components, includ¬ 
ing microelectronics and optoelec¬ 
tronics, must be improved. The goal is 
to provide B-ISDN for the current cost 
of telephone service. 

According to Ohnsorge, to achieve 
this goal it will be necessary to provide 
a 140 megabit-per-second channel equal 
to the cost of today’s telephone chan- 
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nel, which will require 25 gigabit-per- 
second trunk fiber with a repeater spac¬ 
ing of 40 kilometers. Currently, the best 
laboratory performance has been 10 
Gbits/s with a spacing of 80 km. He 
expects the goal to be reached shortly in 
the laboratory and within 10 years in 
commercial applications. 

The information transfer mode on 
the broadband channels until now has 
used STM, which allocates a channel to 
the communicating entities for the 
duration of the session. The proposed 
ATM allows one subscriber link to be 
used for many concurrent communica¬ 
tion sessions. This requires the informa¬ 
tion to be packetized and addressed to 
the receiver. 

Within this high bandwidth environ¬ 
ment, very advanced microelectronic 
technologies are needed to support 
ATM. To support the goal of service 
for everybody, Ohnsorge suggested that 
memory chip capacity must increase by 
almost one order of magnitude and the 
access time decrease by almost two 
orders of magnitude. Additionally, 
microprocessor instruction execution 
rates need to increase by about one 
order of magnitude. 

ATM needs, approaches. Two 

papers, “ATM and Its Challenges to 
VLSI” by U. Killat of Philips and 
“New Communication Transfer Modes 
for the Broadband ISDN” by M. 
Decina of the Politecnico di Milano, 


addressed the requirements and 
approaches to ATM. 

Killat pointed out that B-ISDN is an 
extension of ISDN that will provide the 
customer one or two types of broad¬ 
band channels, in addition to the stan¬ 
dard ISDN D-channel of 16 Kbits/s and 
two B-channels of 64 Kbits/s. Since 
“for broadband services no sound 
predictions of traffic characteristics are 
available,” a central requirement for 
the broadband operation is flexibility. 
The ATM approach is expected to pro¬ 
vide the flexibility that STM cannot. 

“Access and network congestion con¬ 
trol,” said Decina, “are strongly 
required due to the largely unknown 
input traffic profiles and mixtures of 
the multimedia communications of 
future networks: high-speed data, high 
definition graphics, and motion video, 
in addition to voice and bulk/bursty 
low-speed data.” 

Decina described the design of the 
switch necessary to meet the basic per¬ 
formance requirements for ATM as 
“extremely challenging.” In particular, 
the requirements are “overall switch 
office unavailability of less than 10 5 as 
dictated by ISDN network performance 
objectives; cell cross-office delay, 
statistically less than a millisecond, as 
dictated by voice and interactive data; 
and cell loss probability, less than 10 8 , 
as dictated by high-definition full- 
motion video,” he said. 

“The objective of the described 


research and development work was to 
create a key component that is suitable 
for building cost-effective broadband 
switching networks with low power con¬ 
sumption.” That was how D. Boettle 
and H. Preisach of SEL described their 
work in the invited paper, “An 
Advanced 1.5-pm CMOS Crosspoint 
Element for High-Speed (> 140 
Mbits/s) Switch Applications.” 

The chip they developed is a 16 X 16 
crosspoint switch with full broadcast 
capability for broadband communica¬ 
tion networks using either STM or 
ATM. Additionally, the chip provides 
signal regeneration and internal test 
functions. The control and status 
reporting of the chip is performed via a 
microprocessor-compatible 8-bit port. 
The chip size is 33.48 square millimeters 
with 40,000 transistors. The major chip 
area is allocated to the signal regenera¬ 
tion circuits. In tests, using a pseu¬ 
dorandom sequence of 2 23 - 1 the bit 
error rate is less than 10 10 . 

The proceedings, order No. 1940, is 
available from the Computer Society 
Press, Los Alamitos, California, by 
calling (800) CS-BOOKS or (714) 
821-8380 in California. 

The 1990 conference will be held May 
7-9 in Israel. Since the focus of the con¬ 
ference alternates between hardware 
and software each year, “Computer 
Systems and Software Engineering” has 
been selected as next year’s conference 
theme. 


‘Meeting Tests of Time’ ITC theme captures 20 years of testing excellence 


“Meeting the Tests of Time” will be 
the theme of the 20th International Test 
Conference August 27-31 in Washing¬ 
ton, DC, showcasing test technology’s 
past, present, and future. 

Ray Oberly, who retired from IBM in 
1987, is serving as the general chair of 
the IEEE Computer Society-sponsored 
conference. Ray Mercer of the Univer¬ 
sity of Texas at Austin is the program 
chair. 

William Gosling, technical director at 
Plessey and chairman of Plessey 
Research and Technology, will present 
the keynote address August 29 entitled 
“Twenty Years of ATE.” Gosling will 
look forward to testing methodologies 
in the 1990s as he discusses past and 
present techniques. 

“More development and fine-tuning 
will be required,” asserts Gosling in his 
“time machine” view of the industry. 

The author of over 60 scientific 
papers and eight books, Gosling is also 


a member of the National Committee 
for Superconductivity and the Defense 
Science Advisory Board. 

Invited ITC 89 speaker Thomas W. 
Williams of IBM will present a talk 
entitled “Test Technology 20 Years and 
Beyond.” Covering two decades of 
design changes, Williams will discuss 
the impact design, development, and 
manufacturing processes have on test 
technology. 

As founder and chair of the Com¬ 
puter Society-sponsored Workshop on 
Design for Testability, Williams brings 
an international perspective to real- 
world issues. During the plenary ses¬ 
sion, Williams will be presented the 
IEEE fellow award in recognition of his 
leadership and contributions to design 
for testability. 

According to Mercer, papers selected 
for presentation at ITC 89 “spread 
across the entire spectrum of electronic 
testing—from ICs to systems—and con¬ 
tain the latest theoretical results and 


practical applications.” 

Significant topic areas include: 

• new boundary-scan standards and 
methods for testing boards; 

• quality issues, including electrical, 
thermal and material variables; 

• test pattern generation algorithms 
for sequential circuits and delay fault 
detection; 

• tester hardware architecture, pin 
electronics, and electron beam probing; 

• testing methods for a variety of 
complex devices; and 

• synthesis for testability. 

The conference’s technical program 
includes 111 papers, five panel discus¬ 
sions, a poster session, and 14 tutorials. 
As with last year’s conference, over 
3,000 test professionals from around 
the world are expected to attend. 

Complete information about the con¬ 
ference is available by contacting ITC 
89, PO Box 264, Mt. Freedom, NJ 
07970, phone (201) 895-5260. 
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CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in upcoming 
special issues. 

Recent Developments in Operating Systems has been 
selected as the theme for the May 1990 edition. Tutorial, sur¬ 
vey, descriptive, case-study, applications-oriented, or peda¬ 
gogic manuscripts are sought. 

Suggested topics include 

• Distributed systems 

• Multiprocessor systems 

• Real-time systems 

• Security and privacy 

• Workstations 

• File systems 

• Performance evaluation 

• Reliability 

• Virtual memory 

• Future trends 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract of the manuscript is due by August 15, 
1989, and eight copies of the full manuscript must be submit¬ 
ted by October 1, 1989, to Joseph Boykin, Encore Computer 
Corp., 257 Cedar Hill St., Marlborough, MA 01752; phone 
(508) 460-0500, ext. 2720; Internet boykin@encore.com; 
UUCP encorelboykin 

Authors will be notified of acceptance by December 15, 
1989. The final version of the manuscript is due no later than 

February 1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Boykin or to Bruce Shriver, Editor-in-Chief, Computer, Univer¬ 
sity of Hawaii, 2404 Malle Way, Honolulu, HI 96822; Internet 
shriver@uhccux.uhcc.hawaii.edu 


Formal Methods for Software Engineering has been se¬ 
lected as the theme for coordinated special issues of 
Computer, IEEE Software, and IEEE Transactions on Soft¬ 


ware Engineering in September 1990. 

Formal methods are design and construction methods ex¬ 
plicitly based on well-defined mathematical formalisms. Ex¬ 
amples include VDM, Z, box structures, traces, predicate 
transformers, state transition systems, axiomatic data types, 
and many more. 

These methods promise 

(1) better control over the system development process 
through clarity and precision of specification and then 
of development steps and 

(2) reduced error commission and persistence through 
rigor, systematic review, and formal analysis. 

Much progress has been made in using formal methods, 
developing support systems for them, and evaluating their 
applicability on industrially oriented problems. Applications to 
critical systems are appearing worldwide, and there is now 
some commercial interest based on advances in verifiable 
execution environments. Several standards groups are using 
formal methods, and one — VDM — is undergoing the inter¬ 
national standards process. 

For the coordinated set of articles planned in September 
1990, multiple submissions of different types (for example, a 
case study with accompanying research description) are 
permitted. Computer will publish a survey plus tutorial, IEEE 
Software will carry application case studies, and IEEE Trans¬ 
actions on Software Engineering will publish research papers. 

Submit application case studies, tutorials, and surveys to 
Susan Gerhart, MCC Software Technology Program, 3500 W. 
Balcones Dr., Austin, TX 78759; phone (512) 338-3492; fax 
(512) 338-3899; e-mail gerhart@mcc.com 

Submit research contributions to Nancy Leveson, Informa¬ 
tion and Computer Science Dept., University of California, 
Irvine, CA 92717; phone (714) 856-5517; fax (714) 856-4056, 
e-mail nancy@ics.uci.edu 

Drafts must be submitted no later than October 1, 1989. 
Reviews will be completed by March 1, 1990, and revisions 
must be completed by May 1, 1990. 

Reviewers are sought who are willing to adhere to a tight 
timetable for publication of these special issues. 


IEEE Trans. Parallel and Distributed 
Computing will begin quarterly publi¬ 
cation in January 1990. Sample subject areas 
include parallel and distributed architectures, 
parallel and distributed software, and paral¬ 
lel algorithms and applications. Submit pa¬ 
per to Tse-yun Feng, Editor-in-Chief, IEEE 
TPDC, Computer Engineering Program, 

Dept, of Electrical Engineering, Pennsylva¬ 
nia State Univ., University Park, PA 16802. 

(r fev IEEE Micro seeks articles for general- 
interest issues in 1990. Suggested top¬ 
ics include neural networks, artificial intelli¬ 


gence, special-purpose computers, optical 
computers and interfaces, workstations, use 
of microprocessors in parallel computers, 
VHDL design, silicon compilation, and bio¬ 
logical computing. Tutorials are welcome on 
all micro-related topics. Submit manuscripts 
to Joe Hootman, Editor-in-Chief, EE Dept., 
Univ. of North Dakota, PO Box 7165, Grand 
Forks, ND 58202, phone (701) 777-4331. 

First Int’l Symp. on Artificial Intelligence 
and Mathematics: Jan. 3-5, 1990, Fort Lau¬ 
derdale, Fla. Submit paper to Frederick 
Hoffman, Mathematics Dept., Florida Atlan¬ 


tic Univ., PO Box 3091, Boca Raton, FL 
33431-0991, phone (407) 367-3340. 


First Int’l Conf. on Systems Integra¬ 
ls^ tion: Apr. 23-26, 1990, Morristown, 
N.J. Cosponsors: New Jersey Inst, of Tech¬ 
nology et al. Submit paper by July 25, 1989, 
to Peter A. Ng, Computer and Information 
Science Dept., New Jersey Inst, of Technol¬ 
ogy, Newark, NJ 07102, phone (201) 596- 
3387. 


First Conf. on Visualization in Biomedical 
Computing: May 22-25, 1990, Atlanta. 
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Sponsors: National Science Foundation et al. 
Submit abstract by July 31, 1989, to 
Norberto Ezquerra, Bioengineering Center, 
Georgia Tech, Atlanta, GA 30332, phone 
(404) 894-3964. 

Parbase 90, Int’l Conf. on Databases, Par¬ 
allel Architectures, and their Applications: 

March 6-9, 1990, Miami Beach. Cosponsors: 
Florida International Univ. et al. Submit pa¬ 
per by Aug. 4, 1989, to Parbase 90, School 
of Computer Science, Florida International 
Univ., Miami, FL 33199, phone (305) 554- 
3429 or 3386. 


Eighth Nat’l Conf. on Ada Technology: 

March 5-8, 1990, Atlanta. Submit abstract by 
Aug. 10, 1989 and full paper by Sept. 21, 
1989, to Eighth Nat’l Conf. of Ada Technol¬ 
ogy, US Army Communications — Electron¬ 
ics Command, Attn.: AMSEL-RD-SE-CRM 
(Kay Trezza), Fort Monmouth, NY 07703- 
5000. 


Winter 1990 Usenix Tech. Conf.: Jan. 22- 
26, 1990, Washington, DC. Submit extended 
abstract by Aug. 14, 1989, to Daniel V. 

Klein, Software Engineering Inst., Carnegie 
Mellon Univ., Pittsburgh, PA 15213-3890, 
phone (412) 268-7791. 

18th Computer Science Conf.: Feb. 20-22, 
1990, Washington, DC. Sponsor: ACM. Sub¬ 
mit paper by Aug. 15, 1989, to Barbara Ky- 
riakakis, Computer Science Dept., George 
Mason Univ., Fairfax, VA 22030, phone 
(703) 323-2318. 

IKBCS 89, Second Int’l Conf. on Knowl¬ 
edge-Based Computer Systems: Dec. 11- 
13, 1989, Bombay, India. Sponsor: Govern¬ 
ment of India Dept, of Electronics. Submit 
draft of paper by Aug. 15, 1989, to S. 
Ramani, Nat’l Centre for Software Technol¬ 
ogy, Gulmohar Cross Rd. No. 9, Juhu, Bom¬ 
bay 400 049, India, phone 91 (22) 620-1606. 


IEEE Infocom 90, Conf. on Com- 
'5U' puter Communications: June 3-7, 
1990, San Francisco. Cosponsor: IEEE Com¬ 
munications Society. Submit paper by Aug. 
31, 1989, to M. Gerla, IEEE Infocom 90, 
Computer Science Dept., UCLA, BH 3732H, 
Los Angeles, CA 90024, phone (213) 825- 
2660. 


i£|^l CompEuro 90, IEEE Int’l Conf. on 
'5|? Computer Systems and Software En¬ 
gineering: May 7-9, 1990, Tel Aviv. Co¬ 
sponsors: IEEE, Information Processing As¬ 
soc. of Israel. Submit abstract by Sept. 1, 
1989, to CompEuro 90 Conference Secretar¬ 
iat, c/o ORTRA, 2 Kaufman St., POB 50432, 
Tel Aviv, 61500, Israel, phone 972 (3) 664- 
825. 


^3^ EDAC 90, European Design Automa- 
'54? tion Conf.: Mar. 12-15, 1990, Glas¬ 
gow, Scotland. Submit abstract/paper by 
Sept. 4, 1989, to EDAC 90 Secretariat, CEP 
Consultants, 26-28 Albany St., Edinburgh, 
EH1 3QH, UK, phone 44 (31) 557-2478. 


Int’l J. Intelligent Systems plans a special is¬ 
sue on temporal issues in artificial intelli¬ 
gence. Submit paper by Sept. 8, 1989, to 
Frank D. Anger, Computer Science Dept., 
Florida Inst, of Technology, Melbourne, FL 
32901, phone (407) 725-9756; or Ken Ford, 
Computer Science Div., Univ. of West Flor¬ 
ida, Pensacola, FL 32514, phone (904) 474- 
2551. 

1990 American Control Conf.: May 23-25, 
1990, San Diego, Calif. Sponsor: American 
Automatic Control Council. Submit paper by 
Sept. 15, 1989, to Eliezer Gai, C.S. Draper 
Laboratory, 555 Technology Square, MS 4B, 
Cambridge, MA 02139, phone (617) 258- 
2232. 


1990 Symp. on Interactive 3D Graphics: 

Mar. 18-21, 1990, Snowbird, Utah. Spon¬ 
sors: US Office of Naval Research et al. Sub¬ 
mit extended abstract by Sept. 15, 1989, to 
Rich Riesenfeld, Univ. of Utah, Computer 
Science Dept., 3190 Merrill Engineering 
Bldg., Salt Lake City, Utah 84112, phone 
(801) 581-8224. 

10th Int’l Conf. on Pattern Recogni- 
'5*7 tion: June 17-21, 1990, Atlantic City, 
NJ. Submit paper by Sept. 30, 1989, to John 
Jarvis, Rm. 48601, AT&T Bell Labs, 
Holmdel, NJ 07733, phone (201) 949-2392. 


Ninth Int’l Conf. on Analysis and Optimi¬ 
zation of Systems: June 12-15, 1990, Anti¬ 
bes, France. Sponsor: INRIA. Submit paper 
by Oct. 1, 1989, to Conference Secretariat, 
INRIA, Service des Relations Exterieures, 
Domaine de Voluceau — BP 105, 78153 Le 
Chesnay Cedex, France, phone 33 (l)-39-63- 
5500. 


Disco 90, Int’l Symp. on Design and Im¬ 
plementation of Symbolic Computation 

Systems: Apr. 10-12, 1990, Capri, Italy. 
Submit abstract and paper by Oct. 10, 1989, 
to Alfonso Miola, Dip. Informatica e Sistem- 
istica. Via Buonarroti, 12, 00185 Roma, It¬ 
aly, phone 39 (6) 731-2367. 


NECC 90, 11th Nat’l Educational 
'5i^ Computing Conf.: June 25-27, 1990, 
Nashville, Tenn. Cosponsor: Int’l Council 
for Computers in Education. Submit paper 
by Oct. 15, 1989, to John D. McGregor, 
Computer Studies Dept., Murray State Univ., 
Murray, KY 42071, phone (502) 762-2614. 


Second Int’l Symp. on Databases in 
Parallel and Distributed Systems: 
July 2-4, 1990, Dublin, Ireland. Cosponsor: 
ACM. Submit paper by Oct. 16, 1989, to 
Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David 
Bell, Inst, of Informatics, Univ. of Ulster, 
Jordanstown, County Antrim, Northern Ire¬ 
land BT370QB, phone (0232) 365-131. 


20th Int’l Symp. on Multiple-Valued 
'Sjj* Logic: May 23-25, 1990, Charlotte, 
N.C. Cosponsors: Microelectronic Center of 
North Carolina, Univ. of North Carolina. 


Submit paper by Nov. 1, 1989, to George 
Epstein, Computer Science Dept., Univ. of 
North Carolina at Charlotte, Charlotte, NC 
28223, phone (704) 547-4566. 

J. Parallel and Distributed Computing plans 
a special issue on software tools for parallel 
programming and visualization in June 1990. 
Submit paper by Nov. 1, 1989, to Lionel Ni, 
Computer Science Dept., Michigan State 
Univ., East Lansing, MI 48824-1027, phone 
(517) 353-4386; or K.C. Tai, Computer Sci¬ 
ence Dept., North Carolina State Univ., 
Raleigh, NC 27695-8206, phone (919) 737- 
7862. 


£3^ COIS 90, Conf. on Office Informa- 
'5§? tion Systems: Apr. 25-27, 1990, Cam¬ 
bridge, Mass. Cosponsor: ACM. Submit pa¬ 
per by Nov. 3, 1989, to Fred Lochovsky, 
Computer Science Dept., 10 King’s College 
Circle, Univ. of Toronto, Toronto, Ont. M5S 
1A4, Canada, phone (416) 978-7441. 

ICALP 90, 17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming: July 
16-20, 1990, Coventry, England. Sponsor: 
Int’l Computers, Ltd. Submit extended ab¬ 
stract or draft by Nov. 15, 1989, to Mike S. 
Paterson, Computer Science Dept., Univ. of 
Warwick, Coventry CV4 7AL, UK, phone 44 
(203) 523-194. 


17th Int’l Symp. on Computer Archi- 
'51?' tecture: May 28-31, 1990, Seattle. Co¬ 
sponsor: ACM. Submit paper by Nov. 21, 
1989, to James Goodman, Computer Sci¬ 
ences Dept., Univ. of Wisconsin, 1210 W. 
Dayton, Madison, WI 53706, phone (608) 
262-1204. 


Coling 90, 13th Int’l Conf. on Computa¬ 
tional Linguistics: Aug. 20-25, 1990, 
Helsinki, Finland. Submit paper by Dec. 1, 
1989, to Hans Karlgren, KVAL, Skeppsbron 
26, S-111 30 Stockholm, Sweden, phone 46 
(8) 789-6683. 


ICCC 90, 10th Int’l Conf. on Computer 
Communication: Nov. 5-9, 1990, New 
Delhi, India. Sponsor: Int’l Council on Com¬ 
puter Communication. Submit draft of paper 
by Dec. 4, 1989, to S. Ramani, National 
Centre for Software Technology, Gulmohar 
Cross Rd. No. 9, Juhu, Bombay-400-049, In¬ 
dia, phone 91 (11) 620-1606. 


Cognitiva 90: Nov. 20-23, 1990, Madrid. 
Sponsor: AFCET. Submit abstract by Jan. 
15, 1990, to Cognitiva 90, c/o AFCET, 156 
Bd Pereire 75017 Paris, France, phone 33 
(01) 47-66-24-19. 


DIAC 90, Directions and Implications of 
Advanced Computing: July 28, 1990, Bos¬ 
ton. Sponsor: Computer Professionals for 
Social Responsibility. Submit abstract and 
paper by Mar. 1, 1990, to Douglas Schuler, 
Boeing Computer Services, MS 7L-64, PO 
24346, Seattle, WA 98124-0346, phone 
(206) 865-3226. 
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CALENDAR 


^2^. In the accompanying Calendar, the IEEE Computer Society logo indicates 
the conferences the society is sponsoring and participating in; additional 
conference sponsors are also listed. Other conferences of interest to our readers 
are included, as well. 

For inclusion in Call for Papers or Calendar, submit information six weeks be¬ 
fore the month of publication (i.e., for the September 1989 issue, send infor¬ 
mation for receipt by July 15, 1989) to Chuck Governale, Calendar Dept., Com¬ 
puter, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720. 


July 1989 


CASE 89, Third Int’l Workshop on 
Computer-Aided Software Engineer¬ 
ing, July 17-21, London. Cosponsors: Impe¬ 
rial College of London et al. Contact Elliot 
Chikofsky, Index Technology Corp.. 1 Main 
St., Cambridge, MA 02142 (in North Amer¬ 
ica); or John Jenkins, School of Manage¬ 
ment, Imperial College, London SW7 2PG, 
UK (in other regions). 

Third Int’l Conf. on Image Processing, 

July 18-20, Warwick, England. Sponsor: In¬ 
stitution of Electrical Engineers. Contact 
Conf. Services, IEE, Savoy PL, London 
WC2R 0BL, phone 44 (1) 24-01-871, ext. 222. 

89 VLSI Education Conf. and Exposition, 
July 19-21, Santa Clara, Calif. Contact M. 
Bush, Conf. Management Services, 5 Cle- 
land PI., Menlo Park, CA 94025, phone 
(415) 329-0510. 

Summer Computer Simulation Conf., July 
24-27, Austin, Texas. Sponsor: Society for 
Computer Simulation. Contact SCS, PO Box 
17900, San Diego, CA 92117-7900, phone 
(619) 277-3888. 

Strategies for Production Control Work¬ 
shop, July 25-26, Pittsburgh. Sponsor: Cen¬ 
ter for Integrated Manufacturing Decision 
Systems. Contact Affiliates Program Coordi¬ 
nator. CIMDS. Robotics Inst., Carnegie Mel¬ 
lon Univ., Pittsburgh, PA 15213-3890, 
phone (412) 268-3832. 

1989 Int’l Working Conf. on Workstations 
for Experiments, July 27-29, Lowell, Mass. 
Sponsor: IFIP. Contact Univ. of Lowell Spe¬ 
cial Programs Office, 1 University Ave., 
Lowell, MA 01852, phone (508) 454-4664. 

1989 Int’l Computers in Engineering 
Conf., July 30-Aug. 2, Anaheim, Calif. 
Sponsor: ASME. Contact Donald R. Riley, 
Mechanical Engineering Dept., Univ. of 


Minnesota, 111 Church St. SE, Minneapolis, 
MN 55455. 

SIGGraph 89, 16th Conf. on Com¬ 
puter Graphics and Interactive Tech¬ 
niques, July 30-Aug. 4, Boston. Cosponsor: 
ACM. Contact SIGGraph 89 Conf. Manage¬ 
ment, 111 E. Wacker Dr., Chicago, IL 
60601, phone (312) 644-6610. 


August 1989 


Engineering Database Management Symp., 
Aug. 1-2, Anaheim, Calif. Sponsor: ASME. 
Contact ASME, 345 E. 47th St., New York, 
NY 10017. 

Robexs 89, Workshop on Robotics and 
Expert Systems, Aug. 2-4, Palo Alto, Calif. 
Sponsor: Instrument Society of America. 
Contact Leslie Hoffman, NASA Ames Re¬ 
search Center. MS 244-7, Moffett Field, CA 
94035, phone (415) 694-4048. 

33rd Int’l Technical Symp. on Optical and 
Optoelectronic Applied Science and Engi¬ 
neering, Aug. 6-11, San Diego. Sponsor: 
SPIE. Contact SPIE, PO Box 10, Bellingham, 
WA 98227-0010, phone (206) 676-3290. 

APL 89, Aug. 7-10, New York City. Spon¬ 
sor: ACM. Contact APL 89, PO Box 4368 
GCS, New York, NY 10163, phone (212) 
877-7733. 

Inst, on Signal Processing and Applica¬ 
tions, Aug. 7-11, North Dartmouth. Mass. 
Contact C.H. Chen, Electrical and Computer 
Engineering Dept., Southeastern Massachu¬ 
setts Univ., North Dartmouth, MA 02747, 
phone (508) 999-8475 or 8515. 

18th Int’l Conf. on Parallel Processing, 

Aug. 8-12, St. Charles, Ill. Sponsor: Pennsyl¬ 
vania State Univ. Contact Tse-yun Feng. 
Electrical Engineering Dept.. Pennsylvania 
State Univ., 121 Electrical Engineering East, 


University Park, PA 16802, phone (814) 
863-1469. 


32nd Midwest Symp. on Circuits and Sys¬ 
tems, Aug. 14-15, Urbana. III. Sponsors: 
Univ. of Illinois at Urbana-Champaign, 
IEEE. Contact K.S. Arun, Coordinated Sci¬ 
ence Lab, Univ. of Illinois, 1101 W. Spring- 
field Ave., Urbana, IL 61801-3082, phone 
(217) 333-7678. 


Micro 22, 22nd Workshop on Micro- 
programming and Microarchitecture, 

Aug. 14-16, Dublin, Ireland. Contact Gearold 
R. Johnson, Center for Computer Assisted 
Engineering, Colorado State Univ., Fort 
Collins, CO 80523, phone (303) 491-5543. 

VHDL Methods Workshop, Aug. 14- 

16, Charlottesville, Va. Cosponsor: 
Univ. of Virginia. Contact Ron Waxman, 
Electrical Engineering Dept., Thornton Hall, 
Univ. of Virginia, Charlottesville, VA 
22901, phone (804) 924-6086. 


Eighth Symp. on Principles of Distributed 
Computing, Aug. 14-16, Edmonton, Canada. 
Sponsor: ACM. Contact P. Rudnicki, Univ. 
of Alberta, Edmonton, Alta., Canada T6G 
2H1, phone (403) 432-2983. 


Third Pan Pacific Computer Conf., 
Aug. 15-19, Beijing. Cosponsors: Chi¬ 
nese Computer Federation, Chinese Inst, of 
Electronics. Contact Halbrecht Associates, 
1200 Summer St.. Stamford, CT 06905, 
phone (203) 327-5630; or Hu Qiheng, Aca¬ 
demia Sinica, Beijing, China, phone 232013. 

VLSI 89, Int’l Conf. on Very Large 
Scale Integration, Aug. 16-18, Mu¬ 
nich, West Germany. Cosponsor: IFIP. Con¬ 
tact VLSI 89, Siemens AG, Otto-Hahn-Ring 
6, 8000 Munich 83, Federal Republic of Ger¬ 
many. phone 49 (89) 63-64-60-38.; or R. Pi- 
loty, Inst, fur Datentechnik, Merkstr. 29, 
Darmstadt, F.R.G., phone 49 (6151) 162-076. 


European Workshop on Modelling Au¬ 
tonomous Agents in a Multi-Agent World, 
Aug. 16-18, London. Contact Jean-Pierre 
Muller, Universite de Neuchatel, Institut de 
Mathematiques et Informatique, Chante- 
merle, 20, CH-2000, Neuchatel, Suisse. 


UCLA ACT One, Symp. on Very High- 
Speed Information Networks, Aug. 17-18, 

Los Angeles. Contact Arlene Weber. 3732 
Boelter Hall, UCLA Computer Science 
Dept., Los Angeles, CA 90024, phone (213) 
825-2551. 


Crypto 89, Aug. 20-24, Santa Barbara, 
Calif. Sponsor: Int’l Assoc, for Cryptologic 
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Research. Contact Kevin McCurley, IBM 
Research, K53/802. 650 Harry Rd„ San Jose, 
CA 95120-6099, phone (408) 927-1708. 

IJCA1 89, 11th Int’l Joint Conferences on 
Artificial Intelligence, Aug. 20-26, Detroit. 
Sponsors: AAAI et al. Contact Wolfgang 
Bibel, Computer Science, Univ. of British 
Columbia, 6356 Agricultural Rd„ Vancou¬ 
ver. B.C., V6T 1W5, Canada, phone (604) 
228-3061. 

Beijing Int’l Symp. for Young Computer 
Professionals, Aug. 21-23, Beijing. Spon¬ 
sors: China Assoc, for Science and Technol¬ 
ogy, Chinese Computer Federation. Contact 
Siping Zhang, Inst, of Computing Technol¬ 
ogy, Academia Sinica, PO Box 2704, Bei¬ 
jing, China 100080. 

Working Conf. on Engineering for Hu¬ 
man-Computer Interaction, Aug. 21-25, 

Napa Valley, Calif. Sponsor: IFIP. Contact 
Leonard Bass. Software Engineering Inst., 
Carnegie Mellon Univ.. Pittsburgh, PA 
15213-3890; or Claus Unger, Praktische In- 
formatick II, Univ. of Hagen, Feithstr 140, 
D-5800 Hagen, West Germany. 

12th Int'l Congress on Cybernetics, Aug. 
21-15, Namur, Belgium. Sponsor: Int’l As¬ 
soc. for Cybernetics. Contact IAC, Palais des 
Expositions, Place Andre Rijckmans, B- 
5000, Namur, Belgium, phone (32) 81-73- 
52-09. 


28th Technical Symp.: Aug. 24, Gaithers¬ 
burg, Md. Sponsors: Washington, DC. chap¬ 
ter of ACM and NIST. Contact Milton S. 
Hess, American Management Systems, 1525 
Wilson Blvd., Arlington, VA 22209, (703) 
841-5942. 


ITC 89, Int’l Test Conf., Aug. 27-31, 

Washington, DC. Cosponsor: IEEE 
Philadelphia Section. Contact ITC 89, PO 
Box 264, Mt. Freedom, NJ 07970, phone 
(201) 895-5260. 


Congress 89, 11th World Computer 
Congress, Aug. 28-Sept. 1, San Fran¬ 
cisco. Sponsor: IFIP. Contact Congress 89, 
PO Box 18-P, Denver, CO 80218, phone 
(303) 831-6338; Adrian J. Basili, AT&T, 30 
Knightsbridge Rd„ Piscataway, NJ 08854; or 
Stephen Yau, Univ. of Florida, CIS Dept., 
Rm. 301, Gainesville. FL 32611, phone 
(904) 335-8006. 

AIME 89, Second European Conf. on Arti¬ 
ficial Intelligence in Medicine, Aug. 29-31, 

London. Cosponsors: European Society of 
Artificial Intelligence in Medicine, British 
Medical Informatics Society. Contact AIME 
89. Gothic House, Barker Gate, Nottingham, 
England NG1 1JU. 


September 1989 


ASE 89, Int’l Conf. on Applications of Su¬ 
percomputers in Engineering, Sept. 5-7, 

Southampton, England. Contact Liz New¬ 
man, Computational Mechanics Inst., 


Ashurst Lodge, Ashurst, Southampton, S04 
2AA, England, UK, phone 44 (0) 42-12- 
92-853. 


12th Int’l Conf. on Fault-Tolerant Systems 
and Diagnostics, Sept. 5-7, Prague, Czecho¬ 
slovakia. Sponsor: Czechoslovak Scientific 
and Technical Society. Contact Jan Hlav- 
icka, Czech Technical Univ., Dept, of Com¬ 
puters, Prague, CSSR. 

ICIP 89, Int'l Conf. on Image Processing, 
Sept. 5-8, Singapore. Sponsors: IEEE Sin¬ 
gapore Section, Nat’l Univ. of Singapore. 
Contact Meeting Planners Pte. Ltd., 100 
Beach Rd„ No. 33-01, Shaw Towers, Sin¬ 
gapore 0718, Republic of Singapore, phone 
(65) 297-2822. 


,£3^1 Arith 9, Ninth Symp. on Computer 
Arithmetic, Sept. 6-8, Santa Monica, 
Calif. Contact Algirdas Avizienis, Computer 
Science Dept., Univ. of California at Los An¬ 
geles, 3732G Boelter Hall, Los Angeles, CA 
90024, phone (213) 825-3028. 


Seventh Pacific Northwest Software Qual¬ 
ity Conf., Sept. 10-12, Portland, Ore. Con¬ 
tact Dick Hamlet, Computer Science Dept.. 
Portland State Univ., PO Box 751, Portland, 
OR 97207-0751. 


European Software Engineering Conf., 
Sept. 11-15, Warwick, England. Sponsor: 
British Informatics Society. Contact BISL, 
13 Mansfield St., London W1M 0BP. UK, 
phone 01-637-0471. 


Midcon 89, Sept. 12-14, Rosemont, III. 
Sponsor: IEEE. Contact Midcon 89, 8110 
Airport Blvd., Los Angeles, CA 90045, 
phone (800) 421-6816. 


Canadian Conf. on Electrical and 
Computer Engineering, Sept. 17-20, 

Montreal. Cosponsor: Canadian Society of 
Electrical Engineering. Contact Micha Avni, 
CCECE 89. PO Box 577, Desjardins Postal 
Station, Montreal. Que., Canada, H5B 1B7, 
phone (514) 283-0004. 


Workshop on Unix System Administration, 
Sept. 18-19, Somerset, N.J. Contact Thomas 
V. Pottanat, NYNEX, 500 Westchester Ave., 
2D-4, White Plains, NY 10604, phone (914) 
683-2186; or Thomas M. Raleigh, Bell Com¬ 
munications Research, 445 South St., MRE 
2A-343, Morristown, NJ 07960-1910, phone 
(201) 829-4321. 


Compsac 89, 13th Int’l Computer 
’^1^' Software and Applications Conf., 
Sept. 18-22, Kissimmee, Fla. Contact IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


HCI Int’l 89, Third Int’l Conf. on Human- 
Computer Interaction, Sept. 18-22, Boston. 
Cosponsors: Assoc, of American Publishers 
et al. Contact Michael J. Smith, Industrial 
Engineering Dept., Univ. of Wisconsin, 1513 
University Ave., Madison, WI 53706. 

Network Management and Control Work¬ 
shop, Sept. 19-21, Tarrytown, NY. Spon¬ 


sors: IEEE et al. Contact Ivan Frisch, Center 
for Advanced Technology in Telecommuni¬ 
cations, Polytechnic Univ., 333 Jay St., 
Brooklyn. NY 11201, phone (718) 260- 
3050. 


10th Systems Science Int’l Conf., Sept. 19- 

22, Wroclaw, Poland. Contact Jerzy Swiatek, 
Technical Univ. of Wroclaw, Inst, of Control 
and Systems Engineering, Janiszewski St. 
11/17. 50-370 Wroclaw, Poland. 

Fifth Int’l Conf. on Image Analysis and 
Processing, Sept. 20-22, Positano. Italy. 
Sponsors: Int’l Assoc, for Pattern Recogni¬ 
tion et al. Contact Gabriella Sanniti di Baja, 
c/o Istituto di Cibemetica. C.N.R., 1-80072 
Arco Felice, Naples, Italy, phone 39 (81) 
867-1255. 


Second ASIC, Application-Specific 
Integrated Circuit Seminar, Sept. 25- 

28, Rochester, N.Y. Contact Lynne M. 
Engelbrecht, 170 Mt. Read Blvd., Rochester, 
NY 14611, phone (716) 328-2310; or Jon K. 
Edwards, Eastman Kodak. Dept. 434. FI. 1, 
Bldg. 9. Rochester, NY 14650, phone (716) 
726-9222. 


Computational Intelligence 89 
Symp., Sept. 25-29, Milan, Italy. Co¬ 
sponsor: ACM. Contact Luc Steels, Free 
Univ. Brusselles, Al Lab, Pleinlaan 2, Ge- 
louw K 2 B-1050, Brussels, Belgium. 


Third Int'l Workshop on Distributed Algo¬ 
rithms, Sept. 26-28, Nice, France. Contact 
Jean-Claude Bermond, LRI, Bat 490, Univer- 
site Paris-Sud, 91405 Orsay, France. 


.£2^, Performance Evaluation, Reliability, 
and Exploitation of Computer Sys¬ 
tems, Sept. 26-29, Walbrzych, Poland. Spon¬ 
sors: Polish Informatic Society et al. Contact 
George J. Anders, Stations and Underground 
Section, Electrical Research Dept., Ontario 
Hydro, 800 Kipling Ave., KR 151, Toronto. 
Ont., Canada M8Z 5S4, phone (416) 231-4111. 


/£3^| Second IEEE Workshop on Worksta- 
tion Operating Systems, Sept. 27-29, 

Pacific Grove, Calif. Contact Joseph Boykin. 
Encore Computer, 257 Cedar Hill St., Marl¬ 
borough, MA 01752, phone (617) 460-0500. 


27th Allerton Conf. on Communication, 
Control, and Computing, Sept. 27-29, Mon- 
ticello, Ill. Sponsor: Univ. of Illinois at Ur- 
bana-Champaign. Contact J.V. Medanic or 
P.R. Kumar, Allerton Conf., Coordinated 
Science Lab, Univ. of Illinois. 1101 W. 
Springfield Ave., Urbana, IL 61801-3082. 


October 1989 


Fourth Knowledge Acquisition for Knowl¬ 
edge-Based Systems Workshop, Oct. 1-6, 

Banff, Canada. Sponsor: American Assoc, for 
Artificial Intelligence. Contact John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, 

Seattle, WA 98124, phone (206) 865-3253. 
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ICCD 89, IEEE Int’l Conf. on Com- 
'gp' puter Design, Oct. 2-4, Cambridge, 
Mass. Contact Sumit Das Gupta, IBM, Bldg. 
306, ZIP 3A1, Hopewell Junction, NY 
12533, phone (914) 894-0540; or Giovanni 
DeMicheli, Stanford Univ., Center for Inte¬ 
grated Systems, Rm. 129, Stanford, CA 
94305, phone (415) 725-3632. 

CAPE 89, Computer Applications in Pro¬ 
duction Engineering Conf., Oct. 2-5, To¬ 
kyo. Sponsors: IFIP, IPSJ, JSPE. Contact 
Business Center for Academic Societies of 
Japan, 2-40-14, Hongo, Bunkyo-ku, Tokyo 
113, Japan, phone 81 (3) 817-5831. 

,£5^. Second Int’l Workshop on Software 

Configuration Management, Oct. 3- 

6, Princeton, N.J. Cosponsors: ACM, 
Gesellschaft fur Informatik. Contact Thomas 
Murphy, Siemens Research, 755 College Rd. 
E, Princeton, NJ 08540, phone (609) 734- 
6560. 

1989 IEEE Ultrasonics Symp., Oct. 3-6, 
Montreal. Sponsor: IEEE Ultrasonics, Ferro- 
electrics, and Frequency Control Society. 
Contact Herman van de Vaart, Allied-Signal, 
Box 1021R, Morristown, NJ 07960, phone 
(201) 455-2482; or Narendra K. Batra, Code 
6385, Naval Research Lab, Washington, DC, 
20375-5000, phone (202) 767-3505. 

ITU-COM 89, First World Electronic 

Media Symp., Oct. 3-8, Palexpo, Ge¬ 
neva, Switzerland. Contact ITU-COM 89 
Secretariat, Int’l Telecommunication Union, 
Place des Nations, CH-1211 Geneve 20, 
Switzerland, phone 41 (22) 99-5190. 

Fifth Int’l Conf. on Computer-Aided 

Test Processing and Its Applications, 
Oct. 4-6, Cambridge, Mass. Cosponsors: 
INCA et al. Contact John Miller, INCA, PO 
Box 2, Dun Laoghaire, County Dublin, Ire¬ 
land, phone 353 (1) 772-941. 

Workshop on Experiences with 
*5*7 Building Distributed and Multi¬ 
processor Systems, Oct. 5-6, Fort Lauder¬ 
dale, Fla.. Cosponsors: Usenix et al. Contact 
George W. Leach, PO Box 2826, MS LG- 
129, Largo, FL 34649-2826, phone (813) 
530-2376. 

Eighth Symp. on Reliable Distributed 
*^p Systems, Oct. 10-12, Seattle. Contact 
Jane W.S. Liu, Computer Science Dept., 

Univ. of Illinois, 1101 W. Springfield Ave., 
Urbana, IL 61801-3082, phone (217) 333- 
6769 or 0135. 

14th Conf. on Local Computer Net- 
^*7 works, Oct. 10-12, Minneapolis. Con¬ 
tact Ron Rutledge, Martin Marietta Energy 
Systems, Oak Ridge Nat’l Lab, Bldg. 4500N, 
MS 6271, PO Box 2008, Oak Ridge, TN 
37831-6271, phone (615) 576-7643. 

^8^, Fifth Int’l Software Process Work- 
*^p shop, Oct. 10-13, Kennebunkport, 
Maine. Cosponsors: Rocky Mountain Inst, of 
Software Engineering et al. Contact De- 
wayne Perry, AT&T Bell Labs, Rm. 3D-454, 
600 Mountain Ave., Murray Hill, NJ 07974, 
phone (201) 582-2529. 


Int’l Symp. on Computer Architecture and 
Digital Signal Processing, Oct. 11-14, Hong 
Kong. Sponsor: IEEE. Contact Wan-Chi Siu, 

• Dept., Hong Kong 


£3^ Fourth Int’l Workshop on High- 
Level Synthesis, Oct. 15-19, Ken¬ 
nebunkport, Maine. Cosponsor: ACM. Con¬ 
tact Gaetano Borriello, Computer Science 
Dept., FR 35, Univ. of Washington, Seattle, 
WA 98195, phone (206) 543-1695. 

Data and Knowledge Systems for 
Manufacturing and Engineering, 

Oct. 16-18, Gaithersburg, Md. Cosponsor: 
ACM. Contact Lawrence A. Rowe, Computer 
Science Div. — EECS, Univ. of California, 
Berkeley, CA 94720, phone (415) 642-5117. 

i£3^j CSM 89, Conf. on Software Mainte- 
nance, Oct. 16-19, Miami, Fla. Contact 
CSM 89, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013; or 
Wilma Osborne, NIST, Bldg. 225, Rm. 

B266, Gaithersburg, MD 20899, phone (301) 
975-3339. 

First Int’l Conf. on Artificial Neural Net¬ 
works, Oct. 17-18, London. Sponsor: Insti¬ 
tution of Electrical Engineers. Contact Conf. 
Services, IEE, Savoy PI., London WC2R 
0BL, UK, phone 44 (1) 24-01-871. 

Eighth Int’l Conf. on Entity-Relationship 
Approach, Oct. 18-20, Toronto. Sponsor: 

ER Inst. Contact Frederick H. Lochovsky, 
Computer Science Dept., Univ. of Toronto, 
Stanford Fleming Bldg., 10 King’s College 
Circle, Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-7441. 

Second Int’l Conf. on Solid State and Inte¬ 
grated Circuit Technology, Oct. 22-28, 

Beijing. Sponsors: Univ. of California Exten¬ 
sion, Berkeley, and the Chinese Inst, of Elec¬ 
tronics. Contact Linda Reid, Continuing 
Education in Engineering, Univ. of Califor¬ 
nia Extension, 2223 Fulton St., Berkeley, CA 
94720, phone (415) 642-4151. 

1^1 IEEE Int’l Workshop on Tools for 
*5^ Artificial Intelligence, Oct. 23-25, 

Fairfax, Va. Contact Nikolas G. Bourbakis, 
Machine Vision Research Lab, ECE Dept., 
SITE, George Mason Univ., 4400 University 
Dr., Fairfax, VA 22030, phone (703) 425-3930. 

Int’l Workshop on Defect and Fault 
Tolerance in VLSI Systems, Oct. 23- 
25, Tampa, Fla. Contact Charles H. Stapper, 
Dept. A23, Bldg. 861-1, IBM, Essex Junc¬ 
tion, VT 05452, phone (802) 769-6655. 

1989 Beijing Int’l Conf. on System Simula¬ 
tion and Scientific Computing, Oct. 23-26, 

Beijing, China. Sponsors: Society for Com¬ 
puter Simulation et al. Contact Wen Chuan- 
Yuan, Beijing Inst, of Aeronautics and 
Astronautics, Beijing, China. 

Second Int’l Symp. on Artificial Intelli¬ 
gence, Oct. 23-27, Monterrey, Mexico. Con¬ 


tact Francisco J. Cantu, Inst. Tecnologico de 
Monterrey, ITESM Sue. Correos “J,” Mon¬ 
terrey, N.L., Mexico 64849, phone 52 (83) 
58-20-00. 

® 23rd Asilomar Conf. on Signals, Sys¬ 
tems, and Computers, Oct. 30-Nov. 1, 

Pacific Grove, Calif. Cosponsors: Naval 
Postgraduate School, San Jose State Univ. 
Contact John T. Rickard, Orincon, 9363 
Towne Centre Dr., San Diego, CA 92121, 
phone (619) 455-5530. 

Third IFAC Workshop on Experi- 
ence with the Management of Soft¬ 
ware Projects, Oct. 30-Nov. 1, West Lafay¬ 
ette, Ind. Cosponsors: Purdue Univ. et al. 
Contact Frederic J. Mowle, School of Electri¬ 
cal Engineering, Purdue Univ., West Lafay¬ 
ette, IN 47907, phone (317) 494-3440. 

ISCIS 4, Fourth Int’l Symp. on Computer 
and Information Sciences, Oct. 30-Nov. 1, 
Cesme, Turkey. Contact Asuman Dogac, 
Computer Engineering Dept., Middle East 
Technical Univ., 06531 Ankara, Turkey. 

CIPS Edmonton 89, Oct. 30-Nov. 1, Ed¬ 
monton, Alta., Canada. Sponsor: Canadian 
Information Processing Society. Contact 
Wayne A. Davis, Computing Science Dept., 
Univ. of Alberta, Edmonton, Alta., Canada 
T6G 2H1, phone (403) 492-3976. 

FedCASE 89, Oct. 30-Nov. 2, 
Gaithersburg, Md. Sponsor: Nat’l Inst, 
of Standards and Technology. Contact Mar¬ 
garet H. Law or Wilma M. Osborne, NIST, 
Technology Bldg., Gaithersburg, MD 20899, 
or 2107 Vermont Ave., Landover, MD 20785. 

FOCS 89, 30th Foundations of Com- 
*5jp' puter Science Conf., Oct. 30-Nov. 1, 
Research Park, N.C. Contact Christos Papa- 
dimitriou, Computer Science Dept., Univ. of 
California at San Diego, La Jolla, CA 92093, 
phone (619) 534-2086; or FOCS 89, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


November 1989 


Ninth Symp. on Small Computers in 
the Arts, Nov. 3-5, Philadelphia, Pa. 
Cosponsor: Small Computers in the Arts Net¬ 
work. Contact Dick Moberg, 338 S. Quince 
St., Philadelphia, PA 19107, phone (215) 
834-1511. 

ICCAD 89, IEEE Int’l Conf. on Com- 
*?»p' puter-Aided Design, Nov. 6-9, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact Andrezej J. 
Strojwas, ECE Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 
268-3530; or IEEE Computer Society, 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 
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Sponsors: US Dept, of Energy et al. Contact 
Randolph A. Reitmeyer, Electronics Tech¬ 
nology and Devices Lab., Attn.: SLCET-I, 

Ft. Monmouth, NJ 07703-5000, phone (201) 
544-3465. 

Fifth Int’l Congress on Advances in Non¬ 
impact Printing Technologies, Nov. 12-17, 

San Diego, Calif. Sponsor: Society for Imag¬ 
ing Science and Technology. Contact Wayne 
Jaeger, Tektronix, PO Box 500, MS 50-321, 
Beaverton, OR 97077, phone (503) 627- 
6714. 

Prociem 89, Second Conf. on Productivity 
through Computer Integrated Engineering 
and Manufacturing, Nov. 13-15, Orlando, 
Fla. Sponsor: Florida High Technology and 
Industry Council. Contact Vince Amico, 

Univ. of Central Florida, College of Ex¬ 
tended Studies, PO Box 25000, Orlando, FL 
32816, phone (407) 275-2123. 

IFIP Int’l Workshop on Applied Formal 
Methods for Correct VLSI Design, Nov. 
13-16, Leuven, Belgium. Cosponsors: IFIP, 
Interuniversity Micro Electronics Center. 
Contact Luc Claesen, IMEC vzw, Kapeldreef 
75, B-3030 Leuven, Belgium phone 32 (16) 
281-203. 


.££N Supercomputing 89, Nov. 13-17, 

55 Reno, Nev. Cosponsor: ACM. Contact 
F. Ron Bailey, MS 258-5, NASA Ames Re¬ 
search Center, Moffett Field, CA 94035, 
phone (415) 694-4500. 


Semiconductor Manufacturing Conf., Nov. 
14-15, Phoenix. Sponsor: Society of Manu¬ 
facturing Engineers. Contact Karen L. Kam- 
merer, Technical Committee Projects Dept., 
SME, 1 SME Dr., PO Box 930, Dearborn, MI 
48121, phone (313) 271-1500. 


12th Western Educational Computing 
Conf., Nov. 16-17, Burlingame, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Contact Judah Rosenwald, Ex¬ 
tended Education, NAD 153, San Francisco 
State Univ., 1600 Holloway, San Francisco, 
CA 94132, phone (415) 338-1212. 


AIDA 89, Fifth Conf. on Artificial Intelli¬ 
gence and Ada, Nov. 16-17, Fairfax, Va. 
Cosponsors: George Mason Univ., Inst, for 
Defense Analyses, Software Productivity 
Consortium. Contact AIDA 89, Computer 
Science Dept., George Mason Univ., 4400 
University Dr., Fairfax, VA 22030, phone 
(703) 323-2713. 


Tencon 89, IEEE Region 10 Conf., Nov. 
22-24, Bombay, India. Sponsor: IEEE Bom¬ 
bay Section. Contact Kirit J. Sheth, Hako- 
tronics Pvt. Ltd., Victoria Gardens, Bombay 
400 027, India, phone 91 (22) 872-2888. 


IEEE Workshop on Interpretation of 
'5^' 3D Scenes, Nov. 27-29, Austin, Texas. 
Contact Anil K. Jain, Computer Science 
Dept., Michigan State Univ., A-714 Wells 
Hall, East Lansing, MI 48824, phone (517) 
353-5150. 


December 1989 


WSC 89, Winter Simulation Conf., 
55^ Dec. 3-6, Washington, DC. Cospon¬ 
sors: Society for Computer Simulation et al. 
Contact Sallie Sheppard, Office of Associate 
Provost, 103 Academic Bldg., Texas A&M 
Univ., College Station, TX 77843, phone 
(512) 845-3210; or Philip Heidelberger, IBM 
Research Div., T.J. Watson Research Center, 
Hawthorne, PO Box 704, Yorktown Heights, 
NY 10598, phone (914) 789-7156. 

First Int’l Conf. on Deductive and 
'55' Object-Oriented Databases, Dec. 4-6, 

Kyoto, Japan. Cosponsors: Information Pro¬ 
cessing Society of Japan et al. Contact Won 
Kim, MCC, 3500 W. Balcones Center Dr., 
Austin, TX 78759, phone (512) 338-3439; 
Jean-Marie Nicholas, ECRC Arabellastr. 17, 
8000 Munich 81, FRG, phone 49 (89) 926- 
99-110; or Shojiro Nishio, Applied Math and 
Physics Dept., Faculty of Engineering, 

Kyoto Univ., Toyonaka, Kyoto, 606 Japan, 
phone 81 (75) 751-2111, ext. 5513. 

Fifth Aerospace Computer Security 
'55' Applications Conf., Dec. 4-8, Tucson, 
Ariz. Contact Marshall Abrams, Mitre Corp., 
7525 Colshire Dr., McLean, VA 22102, 
phone (703) 883-6938. 

10th Real-Time Systems Symp., Dec. 
55 5-7, Santa Monica, Calif. Contact Al 
Mok, Computer Science Dept., TAY 3-140C, 
Univ. of Texas, Austin, TX 78712, phone 
(512) 471-9542. 

SIGSoft 89, Third Testing, Analysis, 
55 and Verification Symp., Dec. 6-8, 

Key West, Fla. Cosponsor: ACM. Contact 
Richard A. DeMillo, Purdue Univ., Com¬ 
puter Science Dept., West Lafayette, IN 
47907, phone (317) 494-7823. 

Third Int’l Workshop on Petri Nets 
55 and Performance Models, Dec. 11-13, 

Kyoto, Japan. Cosponsors: Society of Instru¬ 
ment and Control Engineers et al. Contact 
Shojiro Nishio, Applied Math and Physics 
Dept., Faculty of Engineering, Kyoto Univ., 
Toyonaka, Kyoto, 606 Japan, phone 81 (75) 
751-2111, ext. 5513. 


Fourth SIAM Conf. on Parallel Processing 
for Scientific Computing, Dec. 11-13, Chi¬ 
cago. Sponsor: Society for Industrial and 
Applied Mathematics. Contact SIAM Conf. 
Coordinator, 117 S. 17th St., 14th Floor, 
Philadelphia, PA 19103-5052, phone (215) 
564-2929. 


IKBCS 89, Second Int’l Conf. on Knowl¬ 
edge-Based Computer Systems, Dec. 11-13, 
Bombay, India. Sponsor: Government of In¬ 
dia Dept, of Electronics. Contact S. Ramani, 
Nat’l Centre for Software Technology, Gul- 
mohar Cross Rd. No. 9, Juhu, Bombay 400 
049, India, phone 91 (22) 620-1606. 


rence R. Odess, Ortra, PO Box 50432, 6lS()0 
Tel Aviv, Israel, phone 972 (3) 971-3991 or 
664-825. 

Ninth Conf. on Foundations of Software 
Technology and Theoretical Computer Sci 
ence, Dec. 19-21, Bangalore, India. Contact 
C.E. Veni Madhavan, Tata Research Devct 
opment and Design Center, I Mangaldas Rd.. 
Pune 411001, India, phone (212) 662-453. 

Sixth Israeli Conf. on Artificial Intelli¬ 
gence and Computer Vision, Dec. 26-27, 

Tel Aviv. Sponsor: Information Processing 
Assoc, of Israel. Contact 1PA, PO Box 
13009, 91130 Jerusalem, Israel. 


January 1990 


First Int’l Symp. on Artificial Intelligence 
and Mathematics, Jan. 3-5, Fort Lauder¬ 
dale, Fla. Contact Frederick Hoffman, 
Mathematics Dept., Florida Atlantic Univ., 
PO Box 3091, Boca Raton, FL 33431-0991. 
phone (407) 367-3340. 

HICSS 23, 23rd Hawaii Int’l Conf. 
55 on System Sciences, Jan. 3-6, Kona. 
Hawaii. Cosponsor: Univ. of Hawaii. Con¬ 
tact Luqi, Computer Science Dept., Naval 
Postgraduate School, Monterey, CA 93943. 
phone (408) 646-2735. 

Winter 1990 Usenix Tech. Conf., Jan. 22- 

26, Washington, DC. Contact Daniel V. 
Klein, Software Engineering Inst., Carnegie 
Mellon Univ., Pittsburgh, PA 15213-3890, 
phone (412) 268-7791. 


fN. Int’l Conf. on Wafer Scale Integra- 
5 ti°m Jan. 23-25, San Francisco. Con- 
;t Joe Brewer, 351 White Cedar Ln., Sev- 
na Park, MD 21146, phone (301) 765-1247. 


February 1990 


Sixth Int’l Conf. on Data Engineer- 
55 >ng, Feb. 5-9, Los Angeles. Contact 
Joseph E. Urban, College of Engineering, 
Univ. of Miami, PO Box 248294, Coral 
Gables, FL 33124, phone (305) 284-2404. 


Eurasip Workshop on Neural Networks, 
Feb. 15-17, Sesimbra, Portugal. Cosponsors: 
European Assoc, for Signal Processing, 
IEEE, Instituto de Engenharia de Sistemas e 
Computadores. Contact Luis B. Almeida. 
INESC, Apartado 10105, P-1017 Lisboa Co¬ 
dex, Portugal, phone 351 (1) 544-607. 


18th Computer Science Conf., Feb. 20-22, 

Washington, DC. Sponsor: ACM. Contact 
Barbara Kyriakakis, Computer Science 
Dept., George Mason Univ., Fairfax, VA 
22030, phone (703) 323-2318. 


Int’l Conf. on CAD/CAM and Ad- 
55 vanced Manufacturing Technology, 
Dec. 19-21, Jerusalem, Israel. Cosponsor: Is 
rael Society for CAD/CAM. Contact Law¬ 


Compcon Spring 90, Feb. 26-Mar. 2, 

55 San Francisco. Contact Kenichi Miura, 
Computational Research Dept., MS B2-7, 
Fujitsu America, 3055 Orchard Dr., San 
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Third Int’l Software for Strategic 
5^ Systems Conf., Feb. 27-28, Huntsville, 
Ala Cosponsors: IEEE Computer Society 
Huntsville Chapter et al. Contact Continuing 
Education Div., Univ. of Alabama in 
Huntsville, Tom Bevill Center 285, 
Huntsville, AL 35899, phone (800) 448- 
4035 or (205) 895-6372. 


March 1990 


Eighth Nat’l Conf. on Ada Technology, 
March 5-8, Atlanta. Contact Eighth Nat'l 
Conf. of Ada Technology, US Army Com¬ 
munications — Electronics Command, Attn.: 
AMSEL-RD-SE-CRM (Kay Trezza), Fort 
Monmouth, NY 07703-5000. 

Parbase 90, Int’l Conf. on Databases, 
Parallel Architectures, and their Applica¬ 
tions, Mar. 6-9, Miami Beach. Sponsofs: 
Florida Int’l Univ. et al. Contact Parbase 90, 
School of Computer Science, Florida Int’l 
Univ.. Miami, FL 33199, phone (305) 554- 
3429 or 3386. 

EDAC 90, European Design Automa- 
'5*7 tion Conf., Mar. 12-15, Glasgbw, 
Scotland. Contact Gordon Adshead, ICL, 26 
Albany St., Edinburgh, EH1 3QH, UK, 
phone 44 (61) 223-1207. 

IEEE Int’l Conf. on Computer Lan- 
'5*7' guages. Mar. 12-16, New Orleans. 
Contact Boumediene Belkouche, Computer 
Science Dept., Tulane Univ., 301 Stanley 
Thomas Hall. New Orleans, LA 70118, 
phone (504) 865-5840. 

1990 Symp. on Interactive 3D Graphics, 
Mar. 18-21, Snowbird, Utah. Sponsors: US 
Office of Naval Research et al. Contact Rich 
Riesenfeld, Univ. of Utah, Computer Science 
Dept., 3190 Merrill Engineering Bldg., Salt 
Lake City, Utah 84112, phone (801) 581-8224. 

IPCCC, Ninth IEEE Int’l Phoenix 
5*7 Conf. on Computers and Communi¬ 
cations, Mar. 21-23, Scotisdale, Ariz. Co¬ 
sponsor: IEEE Communications Society. 
Contact Forouzan Golshani, Computer Sci¬ 
ence Dept., Arizona State Univ., Tempe, AZ 
85287, phone (602) 965-2855. 

ICSE 12, 12th Int'l Conf. on Soft- 
'5*7' ware Engineering, Mar. 26-30, Nice, 
France. Cosponsors: ACM et al. Contact 
Francois-Regis Valette, CERT/DERI, PO 
Box 4026-2, Ave. Edouard Belin-31055 
Toulouse, France, phone (33) 61-55-71-11; 
ICSE 12, AFCET, 156 Bd. Pereire, 75017 
Paris, France; or IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903. phone (202) 371-1013. 


Italy. Cosponsors: EDBT Foundation et al. 
Contact Michael L. firodie. Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan 
Rd„ MS 62, Waltham, MA 02254, phone 
(617) 466-2256. 


April 1990 


May 1990 


F. Blalock, Office of Continuing Education, 
Univ. of North Carolina at Charlotte. Char¬ 
lotte, NC 28223, phone (704) 547-4861. 

17th Int’l Symp. on Computer Archi- 
5*7 tecture. May 28-31, Seattle. Cospon¬ 
sor: ACM. Contact Jean L. Baer or Larry 
Snyder, Univ. of Washington, Computer Sci¬ 
ence Dept., FR-35, Seattle, WA 98195, 
phone (206) 543-1695. 


Disco 90, Int’l Symp. on Design and Im¬ 
plementation of Symbolic Computation 
Systems, Apr. 10-12, Capri, Italy. Contact 
Alfonso Miola, Dip. Informatica e Sistemis- 
tica, Via Buonarroti, 12, 00185 Roma, Italy, 
phone 39 (6) 731-2367. 

,^3^. First Int’l Conf. on Systems Integra- 
'5*7 tion, Apr. 23-26, Morristown, N.J. Co¬ 
sponsors: New jersey Inst, of Technology et 
al. Contact Peter A. Ng, Computer and Infor¬ 
mation Science Dept., New Jersey Inst, of 
Technology, Newark, NJ 07102. phone (201) 
596-3387. 

COIS 90, Conf. on Office Informa- 
'5*7 tion Systems, Apr. 25-27, Cambridge, 
Mass. Cosponsor: ACM. Contact Robert B. 
Allen, 2A-367, Bellcore, 444 South St., Mor¬ 
ristown, NJ 07960-1910, phone (201) 829- 
4280 or 4315. 


June 1990 


10th IEEE Symp. on Mass Storage 
5*7' Systems, May 6-10, Monterey, Calif. 
Contact Bernard T. O’Lear, NCAR, PO Box 
3000, Boulder, CO 80307, phone (303 ) 497- 
1268. 

CompEuro 90, IEEE Int’l Conf. on 
5*7' Computer Systems and Software En¬ 
gineering, May 7-9, Tel Aviv. Cosponsors: 
IEEE, Information Processing Assoc, of Israel. 
Contact CompEuro 90 Conf. Secretariat, c/o 
ORTRA, 2 Kaufman St., PO Box 50432, Tel 
Aviv, 61500, Israel, phone 972 (3) 664-825. 

First Conf. on Visualization in Bio 
5*7 medical Computing, May 22-25, 

Atlanta. Cosponsors: Nat’l Science Founda¬ 
tion et al. Contact Norberto Ezquerra, Bioen¬ 
gineering Center, Georgia Tech, Atlanta, GA 
30332, phone (404) 894-7026 or 3964. 

SIGMetrics 90, May 22-25, Boulder. 

Colo. Sponsor: ACM. Contact Gary J. Nutt, 
Univ. of Colorado, Boulder, CO 80301; or 
Herb Schwetman, MCC, 3500 W. Balcones 
Center Dr., Austin, TX 78759, phone (512) 
338-3428. 


20th Int’l Symp. on Multiple-Valued 
*5*7 Logic, May 23-25, Charlotte, N.C. Co¬ 
sponsors: Microelectronic Center of North 
Carolina et al. Contact George Epstein, Com¬ 
puter Science Dept., Univ. of North Carolina 
at Charlotte, 214 Kennedy Bldg., Charlotte, 
NC 28223, phone (704) 547-4566; or Carolyn 


ZI^, IEEE Infocom 90, Ninth Conf. on 
5*7 Computer Communications, June 3- 

7, San Francisco. Cosponsor: IEEE Commu¬ 
nications Society. Contact Infocom 90, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

Zj^l 10th Int’l Conf. on Pattern Recogni- 
5*7' lion, June 17-21, Atlantic City, NJ. 
Contact Herbert Freeman, CAIP Center, 605 
Hill, Rutgers Univ., New Brunswick, NJ 
08903, phone (201) 932-4208. 

ZiN DAC 90, 27th Design Automation 
5*7' Conf., June 20-29, Orlando. Fla. Co¬ 
sponsor: ACM. Contact Pat Pistilli, MP As¬ 
sociates, 7490 Clubhouse Rd.. Suite 102, 
Boulder, CO 80301, phone (303) 530-4333. 

ZZ^| NECC 90, 11th Nat’l Educational 
5*7 Computing Conf., June 25-27, Nash¬ 
ville, Tenn. Cosponsor: Int’l Council for 
Computers in Education. Contact John D. 
McGregor, Computer Studies Dept., Murray 
State Univ., Murray, KY 42071, phone (502) 
762-2614. 

Zj^i 20th Int’l Symp. on Fault Tolerant 
5*7 Computing, June 26-28, Newcastle 
upon Tyne, England. Contact Neil Speirs, 
Computing Lab, Univ. of Newcastle upon 
Tyne, Newcastle upon Tyne, NE1 7RU, UK, 
phone 44 (91) 232-8511. 


July 1990 


Second Int’l Symp. on Databases in 
5*7 Parallel and Distributed Systems, 
July 2-4, Dublin, Ireland. Cosponsor: ACM. 
Contact Rakesh Agrawal, AT&T Bell Labs, 
Rm. 3D450, 600 Mountain Ave., Murray 
Hill, NJ 07974, phone (201) 582-2250; or 
David Bell, Inst, of Informatics, Univ. of Ul¬ 
ster, Jordanstown, County Antrim, Northern 
Ireland BT370QB, phone (0232) 365-131. 

ICALP 90, 17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming, July 
16-20, Coventry, England. Sponsor: Int’l 
Computers, Ltd. Contact Computer Science 
Dept., Univ. of Warwick, Coventry CV4 
7AL, UK, phone 44 (203) 523-194. 
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BOOK REVIEWS 


Editor: Guy Johnson, School ol Computer Science, Rochester Institute of Technology, Rochester, NY 14623 


Computer Architecture: A Modern Synthesis — Volume 1: Foundations 

Subrata Dasgupta (John Wiley & Sons, New York, 1989, 377 pp., $39.50) 


The literature on computer architec¬ 
ture is extensive and diverse, hence I 
viewed the words “A Modem Synthe¬ 
sis” in this book’s title with a certain 
skepticism. The author, however, de¬ 
livers on the title’s promise: the book 
is modem and it is a synthesis. Al¬ 
though a number of excellent works al¬ 
ready address this subject — for ex¬ 
ample, Computer Systems Architecture 
(J.L. Baer, Computer Science Press, 
1980) and The Design and Analysis of 
Instruction Set Processors (M.R. Bar- 
bacci and D.P. Siewioreck, McGraw- 
Hill, 1982) — they are somewhat out 
of date and view the field from distinct 
perspectives. The current book takes a 
multifaceted look at the subject. 

The author has coined the terms 
“exo-architecture” and “endo-archi- 
tecture.” The former defines properties 
that reflect “the external functional 
and logical features of computers,” 
while the latter defines characteristics 
that “constitute a description of a com¬ 
puter’s internal organization.” For mi¬ 
croprogramming, there is also “micro¬ 
architecture” to denote “the internal 
architecture -— the logical structure 
and functional capabilities — of a 
computer as seen by a microprogram¬ 
mer.” And at a lower level, supporting 
all these, are the traditional register- 
transfer and circuit-level descriptions. 

In a field that sometimes seems to 
thrive on abstraction for its own sake, 1 
found the author’s formulations helpful 
in ordering the difficult and complex 
subject matter. In fact, the book’s 
“synthesis” is largely due to these or¬ 
ganizational descriptions. 

The text is the first of a two-volume 
work dealing with architectural prin¬ 
ciples and issues related to architec¬ 
tural design. This first volume is aimed 
at senior computer science and engi¬ 
neering students and covers “parts and 
subsystems in convenient isolation.” 
The second volume, subtitled Advanced 
Topics , is meant for the graduate level 
and deals with “the design of the 
whole.” 


The text has an excellent, up-to-date, 
and extensive bibliography. Further¬ 
more, these titles do not languish at the 
back of the book but are referenced on 
a substantial number of pages through¬ 
out the text. This in itself makes the 
book a useful reference. Also, each 
chapter has bibliographic remarks, with 
other subjects such as history occasion¬ 
ally added. 


In a field that seems to 
thrive on abstraction for 
its own sake, the author’s 
formulations helped order 
the difficult, complex 
subject matter. 


The book is divided into two parts. 
The first deals with issues common to 
all architectures. It contains a chapter 
on the scope of computer architecture 
and chapters on the technological 
framework and the design process. The 
second part has chapters on the inner 
and outer architectures of register ma¬ 
chines, stacks, language-directed archi¬ 
tectures such as RISC, and aspects of 
memory. 

The first chapter introduces the sub¬ 
ject, defines the different architectural 
levels, and discusses issues regarding 
design disciplines such as the influence 
of software and compilers. The levels 
are illustrated by the VAX family of 
computers. The chapter on technology 
reviews various circuit families, their 
design characteristics, and design prob¬ 
lems in their use. The chapter on the 
design process is an excellent discus¬ 
sion of exactly what constitutes a de¬ 
sign. 

In the second part, the chapters on 
register machines offer detailed discus¬ 
sions of well-known architectures, such 
as the VAX and System/370, as ex¬ 
amples of the architectural principles. 


These chapters also include a discus¬ 
sion of microprogramming. The chap¬ 
ter on stacks discusses stack architec¬ 
tures, while the chapter on language- 
directed architectures includes a very 
nice discussion of the RISC approach 
using such examples as the Berkeley 
RISC machine. A final chapter ex¬ 
plores organization and performance 
characteristics of different types of 
memory. 

The text has many interesting and il¬ 
luminating examples throughout as 
well as thoughtful problems at the end 
of each chapter. These illustrate the 
book’s particular perspective on de¬ 
sign, as opposed to a straight taxonomy 
of computer parts and principles. The 
reader is encouraged to think out the 
various relationships and interconnec¬ 
tions contributing to a design. 

Although the book is aimed at upper- 
level undergraduates, it seems more of 
a graduate-level work and often reads 
like an article for a first-class technical 
journal. The topics are-certainly well 
focused, but they are also extensively 
referenced, with related concepts and 
ideas noted and listed. This is a boon 
to the serious reader but may prove 
distracting to the average student (who 
also will probably not have all the ref¬ 
erences at hand). In this regard, the 
text cannot be called totally self-con¬ 
tained. 

In some cases, 1 also found the level 
of sophistication of the discussion 
quite high. Any computer professional 
with some background in this area 
could profit from this book, if only to 
get a broad view of the topic and infor¬ 
mation on where to look further for 
particular areas of interests. 

The text is a well-written, polished, 
scholarly work, and the author has a 
firm handle on this complex and inter¬ 
esting subject. If it fails in being all 
things to all readers, it is only because 
it covers its main subject so well. 

Joseph M. Kusmiss 

Saint Anselm College 
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The Computer Virus Crisis 

Philip Fites, Peter Johnson, and Martin Kratz (Van Nostrand Reinhold, New York, 1989, 171 pp., $19.95) 


The objective of The Computer Virus 
Crisis is to inform personal computer 
users about the virus phenomenon. The 
authors define viruses, worms, and 
Trojan horses, and describe what vi¬ 
ruses have done and can do to comput¬ 
ers. The book describes famous viruses 
such as the MacMag , nVIR, and Brain 
viruses; discusses high-risk practices; 
recommends “safe hex” practices; and 
discusses and lists antiviral software 
packages along with contacts for ob¬ 
taining the software. 

I looked forward to reviewing this 
book. Computer viruses are a hot topic. 
Viruses have allegedly been written by 
14-year-olds (the HyperAvenger virus). 
Approximately 350,000 Mac users 
were reportedly hit by the MacMag vi¬ 
rus. Unfortunately the Computer Virus 
Crisis is not the book I want. 

The Computer Virus Crisis is aimed 
at a nontechnical audience. Teachers, 
accountants, or managers may find it 
fascinating, but the technical content 
for software professionals is minimal, 
so its value to a professional audience 
is small. The list of antiviral software 
packages may be of value, but such a 
list quickly becomes dated. One con¬ 
cern is the statement in some package 
descriptions that “no indication is 
given in the documentation as to 
whether this is freeware, shareware, or 
a commercial product.” This led me to 
conclude that the book was rather hast¬ 
ily put together. 

In reviewing the technical content, I 
counted 18 misleading or erroneous 
statements, ranging from the fairly 
trivial to what I consider serious mis¬ 
takes. For a trivial example, Fred Co¬ 
hen is credited with coining the term 
“virus.” In fact, Len Aldeman is gen¬ 
erally credited with coining the term; 
Cohen is credited with doing the first 
serious research in the area. 

A more serious example is the sug¬ 
gestion that you can be exposed to a vi¬ 
rus if you are on a network, even if you 
practice “safe hex.” While you may 
be exposed to a worm program if your 
computer is networked, viruses are not 
related to computer networks at all. A 
virus is a program that reproduces by 
modifying existing programs and files. 
A worm is a program that replicates it¬ 
self through a network. The distinction 
can blur at times, and the term virus 
has been misused in the media so much 
that its technical meaning is seriously 
compromised (for example, the In¬ 
ternet worm was originally reported as 


the Internet virus). Increased exposure 
to viruses in a networked environment 
depends on how the network is used, 
not its existence. 

The authors of The Computer Virus 
Crisis define “virus” correctly, even 
pointing out that viruses need not be 


Teachers, accountants, or 
managers may find the 
book fascinating, but the 
technical content for 
software professionals is 
minimal. 


malicious (a point frequently over¬ 
looked in today’s turmoil). However, 
they state that worms alter data and 
code whenever they can get access. 
Neither viruses nor worms are inher¬ 
ently malicious. Shoch and Hupp's 
original work with worms at Xerox 
PARC was aimed at harnessing unused 
resources (see “The Worm Programs— 
Early Experience with Distributed 
Computations,” CACM , Mar. 1982, pp 
172-180). Research in this area has sig¬ 
nificant positive implications for paral¬ 
lel computing. 

The authors of this book consult on 
computer security and legal issues, and 
this bias leads to some interesting, if 
questionable, statements. First, they 
state that most viruses spread through 
Various violations of copyright laws or 
licenses. Second, they state that piracy 
has been a major cause of problems, 
including buggy programs and vapor¬ 
ware (they also state in the text that 


The art of teaching programming has 
been greatly refined over the past few 
years. However, those of us attempting 
to practice the art on a regular basis are 
still frustrated by our inability to teach 
students how to program. Typically, we 
demonstrate how good programs are 
designed and implemented and hope 
that by some osmotic process the stu- 


vaporware comes from releasing buggy 
versions of a program, but the defini¬ 
tion in the glossary is correct). Third, 
they state that games are specifically 
targeted by viruses. They even briefly 
discuss security problems such as pig¬ 
gybacking communication lines, traffic 
analysis, and the salami technique. 

I certainly don’t condone software 
piracy, but viruses are eclectic in their 
attacks. They are just as happy to at¬ 
tack a licensed spreadsheet program as 
a bootlegged game — and the attack 
proceeds in the same manner. The only 
example of a specific application being 
attacked that I am aware of is the tar¬ 
geting of ERIC and VULT by the 
Scores virus (ERIC and VULT were in¬ 
ternal, proprietary, trade-secret devel¬ 
opments at Electronic Data Systems 
that Scores checked for specifically). 

The Computer Virus Crisis reiterates 
one recommendation that I agree with 
wholeheartedly. “Backups are the 
single most important action you can 
take to protect yourself against viral at¬ 
tack. They are also the lowest cost.” 
Backups are vital even if you are never 
infected by a virus. A disk crash can be 
much more damaging than a virus. 

In summary. The Computer Virus 
Crisis appears to have been written 
quickly. It has numerous inconsisten¬ 
cies and errors and is not written for a 
technical audience. A nontechnical au¬ 
dience, however, would find the book 
of value. Technical readers would find 
the ongoing discussion on the VIRUS- 
L Bitnet newsgroup, moderated by 
Kenneth van Wyk of Lehigh Univer¬ 
sity, of more value until a better book 
is written. 

Mark C. Paulk 

Software Engineering Institute 


dent will be able to transfer the knowl¬ 
edge to new and more difficult prob¬ 
lems. All too often we find that the 
process does not work. 

It was with this background that, 
upon receiving this book and noting the 
title, I hung a “Do not disturb” sign 
on the door and devoted the next few 
hours to absorbing its contents, hoping 


A Method of Programming 

Edsger W. Dijkstra and W.H.J. Feijen (translated by Joke Sterringa) (Addison- 
Wesley, Reading, Mass., 1988, 188 pp., $26.95) 
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to find a prescription for automating 
algorithm design. Of course, such an 
expectation was unrealistic. However, I 
did find a rigorous and teachable intro¬ 
duction to program design. 

The central concepts will be known 
to readers familiar with Dijkstra’s 
work on the specification and verifica¬ 
tion of programs. The book is intended 
to be a freshman-level introduction to 
the systematic development of correct 
programs using these concepts. The 
material has been used by the authors 
and others for several years in intro¬ 
ductory programming classes, so we 
know that the approach works and can 
be taught at that level. The mathemati¬ 
cal formalism and terminology re¬ 
quired may be somewhat intimidating 
to the novice, but a lecture-paced pres¬ 
entation will minimize this. Two-thirds 
of the book defines the programming 
elements needed and gives numerous 
and detailed examples of how these 
elements should be included in the de¬ 
sign process. The remainder is devoted 
to an exposition of the mathematical 
logic elements needed. 

Using the flow of water in a cistern 
as an unusual but appropriate analogy, 
the authors introduce computation as a 
process involving changes of state 
from a specified precondition (about 
the input) to the desired postcondition 
(about the output). For example, the 
functional specification for the pro¬ 
gram to compute the square root of an 
integer could be 

U^andXSO) 

; root 
{* = X) ], 

where root represents one of many pos¬ 
sible sequences of states that will 
transform the precondition to the post¬ 
condition. The expansion of root would 
proceed with the selection of a solution 
strategy and its division into functional 
subblocks, each bounded by a verifi¬ 
able precondition and a postcondition. 
This refinement process continues until 
the desired level of detail is reached. 
The resulting program is an implemen¬ 
tation of the original problem specifi¬ 
cation. Its correctness has been estab¬ 
lished by the construction process. 

The next few chapters introduce the 
programming elements — constants, 
expressions, assignment statement, al¬ 
ternative statement, loops, and arrays. 
These elements are intended merely as 
a vehicle for the presentation of the de¬ 
sign process and not elements of some 
new language. In form, they are suffi¬ 
ciently general to include the specific 
variants found in most common lan¬ 


guages. BNF (Backus-Naur Form) is 
used to define syntax, and an excellent 
selection of examples demonstrates 
how each of these elements is incorpo¬ 
rated into the functional specification 
of programs. Throughout the discourse, 
the reader/student is challenged by ad¬ 
ditional exercises. The authors might 
consider including the solutions to 
these exercises in future editions or as 
a supplement to the present edition. 

Assignment statements and permis¬ 
sible expressions are introduced with 
considerable mathematical rigor and a 
cryptic formalism. A sequence of as¬ 
signment statements has the general 

{PI 1; x := £1; {P2(; y := £2; {P3}; 

■ . ■ ; \Pn } 

where P represents pre- and postcondi¬ 
tions. If correctly formed, this se¬ 
quence can be reduced by forward sub¬ 
stitution to the single statement form 

(PI); z :=Ek- [Pn} 

The alternative statement is defined 
as a generalized case statement (my 
terminology), with each statement 
block (Si) guarded by a Boolean ex¬ 
pression ( Bi ) and with the general 
form: 

if 60 -> 50 

□ 61 -> 51 

□ 62 -> 52 


□ Bn -> Sn 
fi 

The repetitive statement (loop) has 
the form 
do 

generalized case statement 
od 

Guards not listed within the loop body 
cause termination of the loop. The pre¬ 
condition and postcondition for the 
loop are the loop invariants. 

The program syntax is extended to 
support the definition of inner blocks. 
An inner block has its own declaration 
and statement list and it extends the 
dimensions of the state space by the 
number of local variables declared. 

The introduction of the programming 
elements concludes with a definition of 
the array data type. A declaration has 
the form 

f(x: 0 < x < N): array of int . 

As a simple example of the use of an 
array in a functional specification, the 


postcondition for finding the location 
of the largest element in an array 
would be 

{0 < k < N and (V i:0 < i < N: f(i) < 

/(*))} 

This section of the book concludes 
by applying this programming method 
to the solution of some well-known 
elementary problems: the minimal seg¬ 
ment sum in a sequence of integers; the 
number of common elements in two 
sequences; the minimum distance be¬ 
tween two ascending sequences; the 
monotonic subsequence of maximum 
length; the inversion count for a per¬ 
mutation of integers; generating num¬ 
bers with factors of 2, 3, and 5 only; 
the shortest path in a directed graph; 
binary search; and longest subse¬ 
quences with certain order properties. 
Since this is intended to be an intro¬ 
ductory text, a few of the chapters in 
this section would be improved by the 
inclusion of a motivating introduction. 

The latter third of the book presents 
the elements of formal logic and defi¬ 
nitions of some of the functional opera¬ 
tors and terms required by this ap¬ 
proach. A summary of the essential 
concepts introduced in the first section 
precedes an extensive set of program¬ 
ming exercises and solutions to a sub¬ 
set of them. 

Instructors of freshman-level courses 
should cover the material in the second 
section before or concurrently with the 
introduction of the programming con¬ 
cepts. Novice programmers should ac¬ 
quire some familiarity with the mathe¬ 
matical terminology and the logic for¬ 
malism before delving too deeply into 
the first section. 

Computer science and computer en¬ 
gineering programs that adhere to the 
US national curriculum models may 
not, for pedagogical reasons, be able to 
base an introductory course on this 
method of programming. The precol¬ 
lege mathematics preparation that our 
students receive may not be adequate. 
However, this material is quite appro¬ 
priate and necessary for advanced 
courses in software engineering, algo¬ 
rithm design, or any course dealing 
with the formal verification of pro¬ 
grams. Our common practice of turning 
students loose in the real programming 
world without a thorough grounding in 
the techniques of producing verifiable 
programs is the principal contributor to 
the unacceptable amount of unreliable 
code that pervades our commercial 
software. 

John D. Holt 

California State University, Fresno 
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A History of Personal Workstations 

Adele Goldberg, ed. (Addison-Wesley, Reading, Mass., 1988, 537 pp., $38.36) 


In January 1986, the Association for 
Computing Machinery sponsored a 
conference on the history of personal 
workstations. The conference brought 
together individuals who shaped the 
personal workstation into what it is to¬ 
day, including Gordon Bell, Douglas 
Ross, Severo Ornstein, J.C.R. Lick- 
lider, Alan Perlis, Doug Englebart, 

Alan Kay, Chuck Thacker, and Wesley 
Clark. This book is an edited record of 
that conference and is the first in a se¬ 
ries of histories from the ACM. 

Technically, the book progresses 
much as the conference did, with each 
chapter representing a corresponding 
conference session. Each session 
speaker was introduced by the session 
moderator, who introduced the speaker 
and led the discussion afterwards. All 
three parts of each session comprise 
each chapter, giving the reader the 
“look and feel” of the conference. 

Gordon Bell presented the keynote 
address in the opening session. During 
his presentation, Bell defined what a 
personal workstation is and commented 
on the evolutionary nature of its devel¬ 
opment. He also hinted that the per¬ 
sonal workstation may well become ex¬ 
tinct via a “decline through replace¬ 
ment or superposition of functions in 
some other form of information proc¬ 
essing appliance (e.g., conventional 
personal computers).” 


The remaining sessions chronicle the 
development of the personal worksta¬ 
tion, covering roughly a 30-year pe¬ 
riod, and expand on a diverse range of 
topics, such as why some projects were 
funded while other were not, the devel¬ 
opment of Arpanet and computer net¬ 
works, various inventions related to 
personal workstations (including the 


This book is a plethora of 
information regarding the 
development of the 
personal workstation. 


mouse), and the development of tech¬ 
nology (both hardware and software) 
that drives some of today’s personal 
computers. 

Where appropriate, the editor has 
included reprints of historically signifi¬ 
cant papers to broaden the reader’s 
perspective. One paper entitled “Man- 
Computer Symbiosis” by J.C.R. Lick- 
lider, originally printed in the IRE 
Transaction on Human Factors in 
Electronics , March 1960, pp. 4-11, has 
provided the focus for researchers in¬ 
volved with the development of per¬ 
sonal workstations since its publica¬ 
tion. By reading this paper and the 


several presentations that reference it, 
the reader can grasp just how far per¬ 
sonal workstations have come, where 
they are today, and how tremendously 
far they must go to satisfy Licklider’s 
desire for a true man-computer sym¬ 
biosis. Clearly, some of the ideas pre¬ 
sented in this paper are still ahead of 

Those individuals who attended the 
conference might view this as a "year¬ 
book”; there is a group photo at the 
front with a list of persons responsible 
for various aspects of the conference. 
The conference program is also in¬ 
cluded. Reading the book may also 
make those not fortunate enough to at¬ 
tend feel as though they had. 

1 believe the book will appeal to a 
wide audience. Engineers will enjoy 
reading about the creative processes 
involved in developing and implement¬ 
ing cutting-edge technology, and others 
will discover interesting facts while 
reading about the fascinating develop¬ 
ment of the personal workstation. 

Simply stated, this book is a plethora 
of information regarding the develop¬ 
ment of the personal workstation. It is 
easy to read, well illustrated, hard to 
put down, and would be a valuable as¬ 
set to any library. 

R.W. Miller 

RM Systems, Honolulu, Hawaii 


Designing Large Real-Time Systems with Ada 

Kjell Nielsen and Ken Shumate (McGraw-Hill, New York, 1988, 464 pp., $49.95) 


The field of real-time-systems de¬ 
sign has received relatively little atten¬ 
tion from researchers, especially re¬ 
searchers on structured programming. 
Yet, this field needs more researcher 
attention than other fields because the 
design of real-time programs is both 
more complex and more critical than 
the design of traditional, time-inde¬ 
pendent programs. 

Designing Large Real-Time Systems 
with Ada makes the need for such re¬ 
search apparent. This excellent book 
shows how little is known about the 
mechanics of real-time systems, and it 
does so despite the absence of any 
powerful intellectual tools (such as the 
divide-and-conquer tools of structured 
programming). The book achieves its 
goal of presenting “a comprehensive 


methodology for the design and im¬ 
plementation of large real time systems 
in Ada.” The authors’ background in 
the field and the profuse illustrative 
material add credibility to the treat¬ 
ment. 

This book is made up of five parts 
and a set of five appendixes. The core 
of the book is in Part 4, which presents 
a complete Ada-oriented design meth¬ 
odology for real-time systems. This 
methodology is the synthesis of several 
existing methodologies; the modular 
approach to software construction op¬ 
eration and test (MASCOT), the design 
approach for real-time systems 
(DARTS), Booch’s object-oriented de¬ 
sign, Yourdon’s structured design, and 
Dijkstra’s layered virtual machines 
methodology. The book also adapts 


these methodologies to Ada as a target 
programming language and proposes 
Ada as a program design language. 

While the authors endeavor to orient 
the design methodology towards Ada, 
they also recognize the virtues of mak¬ 
ing the methodology and its notations 
language-independent. Although this 
ambiguity of purpose is rather unset¬ 
tling at times, it is immaterial for the 
reader who uses Ada as a target pro¬ 
gramming language. The proposed 
methodology uses a combination of 
two approaches, as befits its mixed 
pedigree: a bottom-up approach for 
its interprocess structuring, and a 
top-down approach to structure its 
sequential aspects. 

In Part 5, the authors discuss system¬ 
atic ways to evaluate a real-time design 
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produced by the methodology from 
Part 4. The generation of the design 
and its evaluation must take place 
hand-in-hand during the preliminary 
design and detailed design phases of 
the software life cycle. Part 5 presents 
a set of verification and validation pro¬ 
cedures for real-time designs, along 
with a set of practical design-evalu¬ 
ation guidelines, including trou¬ 
bleshooting checklists. 

The discussion in Part 4 requires a 
good understanding of Ada design prin¬ 
ciples. This is the subject of Part 3. 
Actually, this section transcends the 
specifics of Ada, presenting an over¬ 
view of real-time design principles us¬ 
ing Ada as an illustration. The defini¬ 
tions here include processes (interact¬ 
ing agents executing tasks concur¬ 
rently); packages (mechanisms for in¬ 
formation hiding and data encapsula¬ 
tion); generic functions (as a means to 
promote reusability and parameteriza¬ 
tion); communication media between 
interacting processes; polling mecha¬ 
nisms (that allow a process to poll a 
device for a given condition); and ex¬ 
ception handling mechanisms (for fault 
detection and error recovery). For each 
feature, the authors discuss the Ada 


construct that implements it. 

Parts 1 and 2 offer the background 
for this study. Part 1 discusses the 
characteristic features of real-time sys¬ 
tems: the time factor, the hardware in¬ 
terfaces and their requirements on real¬ 
time software, and the inherent concur¬ 
rency of real-time systems. Part 2 pres¬ 
ents the problems inherent in the de¬ 
sign of large real-time systems. Chief 
among these problems are the nature of 
programming-in-the-large, the use of 
process-abstraction mechanisms to 
tackle system complexity, and the use 
of analysis and design tools. 

The book’s appendixes present five 
case studies: a remote temperature sen¬ 
sor, a draw image problem (implement¬ 
ing a printer facility for drawing 
graphic images), a simple mail system, 
an air traffic control system, and a ro¬ 
bot controller. The book closes with a 
set of bibliographic references and a 
subject index. 

The author says this book can be 
used as a textbook for an advanced un¬ 
dergraduate or graduate text on soft¬ 
ware engineering. This assessment is 
accurate to the extent that “software 
engineering” is a very vague term. It is 
perhaps more fair to say that this book 


is appropriate as a textbook for a 
course on real-time design program¬ 
ming or advanced programming in 
Ada. Such courses are not common in 
computer science curricula, but the 
book could be used as a supplementary 
text for several common courses at the 
upper undergraduate and graduate 
level. 

The author’s opinion that this book 
is useful to practicing Ada program¬ 
mers is fair. Its prerequisites are a 
good understanding of Ada and real¬ 
time systems, as well as some practice 
with design methodologies. 

In summary, this book is very worth¬ 
while, thanks to the extensive experi¬ 
mental wisdom of its authors and the 
voluminous illustrative material. The 
treatment of the subject matter lacks 
formality, though; the authors often in¬ 
troduce formalisms as a second thought 
and make little use of them when they 
do introduce them. On balance, how¬ 
ever, this book would be useful for 
practicing programmers, as well as stu¬ 
dents in computer engineering and 
software engineering. 

Ali Mili 

University of Tunis 


You Don’t Work in a 
Vacuum. Neither Do We. 

Software is more than coding. It’s also 
design, testing, production, validation, 
maintenance. That’s why IEEE Soft¬ 
ware covers the life cycle from conception 
to implementation, sharing results from 
practitioners and researchers. 

Our departments augment this coverage 
with insights on standards, quality 
assurance, human factors, manage¬ 
ment, news, and products. 

We’re what a technical magazine should 
be: Practical. Authoritative. Lucid. 

For subscription information, write IEEE Software, 
10662 Los Vaqueros Cir., Los Alamitos, CA 90720- 
2578, call (714) 821-8380, or use the reader-service 
card. 
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Introduction. The Berkeley Mammoth project is a large research 
project funded by the National Science Foundation to study various 
aspects of massive information storage, management, and use. 
The Electronics Research Laboratory is seeking a person to 
provide technical expertise, leadership, and management for the 
design and development of a high speed local area network and a 
massive storage facility. 

The Job. Responsibilities include maintenance and development 
of systems software for file system, archiving mechanisms, and 
device drivers; topology and load balancing of the network, and 
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responsibility is user interface and other user-level software, and 
the other whose primary responsibility is day-to-day system 
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knowledge of UNIX kernel, I/O system, disk drivers, 4.3BSD 
networking and system performance and experience with network 
design and management. 

The Environment. You will work with state-of-the-art equipment, 
including a Sun workstation on your desk and new technology as it 
becomes available. You will also interact with the internationally 
recognized faculty and PhD students in the Computer Science 
Division. Working on an exciting university research project and 
living in the stimulating intellectual and cultural community of 
Berkeley - combined with an excellent benefits package - makes 
this an attractive opportunity. 

Annual Salary Range: $ 45,100 - 67,700 per year 
Apply: UC Berkeley Personnel Office , Job #01-511-58 
2539 Channing Way, Berkeley, CA 94720 
For more info: contact Diane Leite (415) 642-8882 
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NEW LITERATURE 


Newsletter a HOOT. Jeff McKenna 
of the McKenna Consulting Group 
edits Hotline on Object-Oriented Tech¬ 
nology, a monthly newsletter for soft¬ 
ware professionals by SIGS Publica¬ 
tions. HOOT will consist of four major 
sections: feature articles, regular col¬ 
umns, departments, and columns at 
large. Topics include object-oriented 
analysis and design, languages, envi¬ 
ronments, databases, and applications. 
Nontechnical topics include product 
introductions, events, book reviews, 
education and training, and project 
management. 

The first issue is scheduled for Octo¬ 
ber 1989. A one-year subscription will 
cost $299 in the domestic US and $323 
elsewhere. For more information, con¬ 
tact The McKenna Consulting Group, 
8825 SW Umatilla St., Tualatin, OR 
97062, phone (503) 692-1889. 

Computers with intuition. Authors 
S. Brunak and B. Lautrup explore the 
aspects of computation common to bio¬ 
logical and artificial computers, espe¬ 
cially the role played by architecture, 
in Neural Networks — Computers with 
Intuition (9971-50-938-5, 200 pp„ $34, 
hardcover; 9971-50-939-3, $16, paper). 
The authors suggest that intelligent be¬ 
havior in computers arises from a sym¬ 
biosis between the serial architecture 
of traditional symbol-manipulating 
computers and the massively parallel 
architecture of neural networks, which 
mainly function asymbolically. Contact 


World Scientific Publishing, 687 
Hartwell St., Teaneck, NJ 07666, phone 
(800) 227-7562. 

Intuiting ICs. The second edition of 
Intuitive IC Electronics: A Sophisti¬ 
cated Primer for Engineers and Tech¬ 
nicians (ISBN 0-07-021968-0, 203 pp., 
$35.95 hardcover; ISBN 0-07-021969- 
9, $19.95, paper) by Thomas M. 
Frederiksen explains concepts in elec¬ 
tronics caused by ICs and reflects re¬ 
cent developments in the field. The 
author examines a range of ICs and 
explains how they are used in linear 
and digital circuits, including semicon¬ 
ductor memories. Contact McGraw- 
Hill, 11 W. 19th St., New York, NY 
10011, phone (800) 262-4729. 

More on neural nets. Yoh-Han Pao 
provides a broad perspective of the 
concepts and applications of pattern 
recognition and neural net computing 
in Adaptive Pattern Recognition and 
Neural Networks (ISBN 0-201-12584- 
6, 309 pp., $37.75, hardback). Pao re¬ 
portedly shows how adaptive pattern 
recognition systems can be imple¬ 
mented using neural nets, as well as 
how a neural net perspective on pattern 
information processing provides practi¬ 
cal advantages and stimulates creativ¬ 
ity in finding new approaches. The 
book is published by Addison-Wesley 
and available through Pao’s company, 
AI Ware, 11000 Cedar Ave., Cleve¬ 
land, OH 44106, phone (216) 421-2380. 


June 1989 IEEE Design & Test 

Parallel Simulated Annealing: Accuracy vs. 
Speed in Placement, M.D. Durand 
Simulated annealing is an effective but 
slow process of determining VLSI 
placement. Adding parallelism affects 
accuracy somewhat, but this survey of work 
done on parallel algorithms shows that as 
long as the error does not accumulate, the 
benefits of speed outweigh the loss of 
accuracy. 

Engineering a Device for Electron-Beam 
Probing, William T. Lee 

These guidelines from Schlumberger 
Technologies are step-by-step instructions on 
making sure that devices meet the design and 
manufacturing requirements for probing by 
an electron-beam probing station. An 
explanation of terms and a tutorial look at 
the latest noncontact probing technologies 
provide valuable information for engineers 
working with today’s complex devices. 

Scan Design at NEC, Shigehiro Funatsu, 
Masato Kawai, and Akihiko Yamada 
This technique has its roots at NEC, and 
designers have found that it greatly 
contributes to reduced testing and 
maintenance costs. The authors compare 
four of the most popular implementations, 
including two scan-path approaches. 

A Built-In Test Module for Fault Isolation, 

Nagesh Vasanthavada and Nick Kanopoulos 
This board-level implementation of 
signature analysis uses a built-in module 
called a testing switch to reduce the time it 
takes to isolate faulty chips. Both the time 
and power overhead are better with this tech¬ 
nique than with schemes using built-in logic- 
block observer circuits. 

A D& T Roundtable 

Built-In Self-Test: Are Expectations Too 
High? 

Expectations for BIST are growing beyona 
a simple cost reduction. Managers are 
thinking in terms of zero testability cost. Our 
panel of experts promises a bright future for 
BIST, but warns of the dangers if the test 
community oversells it. 

June IEEE Micro 

THEME ARTICLES 

Guest Editor’s Introduction 

Computer Projects in Japan, Ken Sakamura 

An Overview of the BTRON/286 Specifica¬ 
tion, Ken Sakamura, Yoshiaki Kushiki, and 
Kazuhiro Oda 

White individuals may find the 32-164-bit 
TRON Project’s systems too costly, this 
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16-bit version should be more affordable and 
fill business data and graphics needs. 

A Floating-Point VLSI Chip for the TRON 
Architecture: An Architecture for Reliable 
Numerical Programming, Shumpei 
Kawasake, Mitsuru Watabe, and Shigeki 
Morinaga 

Preliminary evaluations of FPU show a 
good combination of precision and perfor¬ 
mance. It supports IEEE floating-point 
arithmetic and the ANSI C draft proposal. 

The Data-Driven Microprocessor, Shinji 
Komori et al. 

This five-chip set performs real-time signal 
and distributed parallel processing without a 
system dock or centralized control unit. 


SPECIAL FEATURES 

The TransputerT414 Instruction Set, Jean- 
Daniel Nicoud and Andrew Martin Tyrrell 
Have you wondered how to decipher the 
transputer instruction set? Here’s your 
chance to compare it with something you 

A Logical Design Tool for Relational 
Databases, M. Mehdi Owrang O. and W. 
Gamini Gunaratna 

Here’s a way to prevent anomalies from 
affecting the design of your relational 
database. 


July 1989 IEEE Software 

THEME ARTICLES 

Guest Editor’s Introduction 
Parallel Programming: Harnessing the 
Hardware, Shreekant Thakkar 
Last year, a special issue of IEEE Soft¬ 
ware focused on early efforts to develop 
parallel-programming tools. This year, we 
report on the practical results of such 
efforts: environments and languages for par¬ 
allel systems to harness the hardware. 

CODE: A Unified Approach to Parallel Pro¬ 
gramming, J.C. Browne, Muhammed Azam, 
and Stephen Sobek 

An ideal system would let you program 
graphically, specify any component in any 
language, and run it on any architecture. 

Such a prototype is already in use. 

Faust: An Integrated Environment for Paral¬ 
lel Programming, Vincent A. Guarna, Jr., et 
al. 

Designed for the development of large 
scientific applications, Faust includes several 
new tools and integrates existing tools. Some 
components will be ready for public distribu¬ 
tion this year. 


Start/Pat: A Parallel-Programming Toolkit, 

Bill Appelbe, Kevin Smith, and Charlie 
McDowell 

How can you make Fortran code parallel 
without isolating the programmer from 
learning to understand and exploit parallel¬ 
ism effectively? With an interactive toolkit 
that automates parallelization as it educates. 

Multiprocessing Extensions in Spur Lisp, 

Benjamin Zorn, et al. 

With a few flexible, intuitive extensions, 
you can add parallelism to Common Lisp. 
Spur Lisp is the key to writing symbolic 
programs with ease. 

Qlisp: Parallel Processing in Lisp, Ron 
Goldman and Richard P. Gabriel 

There is a serious need for a powerful, 
understandable multiprocessing language. 
Qlisp is an extension to Common Lisp 
designed for parallel symbolic computation. 

Consul: A Parallel Constraint Language, 

Doug Baldwin 

Implicit parallelism has so far had limited 
success. This study suggests that constraint 
languages are a promising new place to look 
for it. 

Comparing Two Parallel Logic- 
Programming Architectures, Evan Tick 
Which performs better on the N-queens 
benchmark, an Or- or And-parallelsystem? 
This article compares the performance of 
seven algorithms on the Sequent Symmetry. 


SPECIAL FEATURES 

Diffusing Software-Engineering Methods, 
Sridhar A. Raghavan and Donald R. Chand 
Technology transfer has become a major 
concern in software engineering. But without 
a framework for diffusing technology among 
practitioners, the transfer problem cannot be 
solved. 


Allow Plenty of Time for Large-Scale Soft¬ 
ware, Ware Myers 

The age of multimillion-line software is 
upon us. But how do we properly estimate 
development time? Three methods point to 
the same conclusion: Don’t rush. 

July 1989 IEEE Computer 
Graphics and Applications 

THEME ARTICLES 

Guest Editors’ Introduction 
Graphics Superworkstations and the Last 
Hurrah, David Salzman and Jack Grimes 

Transparency and Antialiasing Algorithms 
Implemented with the Virtual Pixel Maps 
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SIMULATION BREAKTHROUGH 



Announcing new 

SIMSCRIPT II.5 with SIMGRAPHICS 

Simulation models are now easier to build 
—results are easier to understand 


N ow you can provide the users 
of your SIMSCRIPT II.5 
models with SIMGRAPHICS™ 
-graphical input and animation. 

Results are easy to understand- 
animated pictures, histograms, pie 
charts and plots. 

Because simulation results are 
easily understood, your recommen¬ 
dations are more likely to be acted 
upon. 

Simulation simplified 

SIMSCRIPT II.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. 

Your model development, check¬ 
out, modification and enhancement 
are greatly simplified. 

Many successful applications 
SIMSCRIPT II.5® is a well 
established, standardized, and 
widely used language with proven 
software support. 

Typical applications include: 
military planning, manufacturing, 
communications, logistics, and 
transportation. 


Free trial offer 

The free trial contains every¬ 
thing you need to try SIMSCRIPT 
II.5 on your computer. 

Try the SIMSCRIPT II.5 lan¬ 
guage, the quality and timeliness 
of our support, the accuracy of 
our documentation and the 
facilities for error-checking— every¬ 
thing you need for a successful 
project. 

For 26 years CACI has provid¬ 
ed trial use of its simulation 
software-no cost, no obligation. 
Act now—free training offer 

For a limited time we also in¬ 
clude free training. Call today to 
avoid disappointment-class size is 
limited. 

SIMSCRIPT II.5 is available on 
most popular computers including 
PC’s running under OS/2, the 
Mac II, and workstations. 

For immediate information 

Call Doug Dittrich at (619) 
457-9681, or FAX (619) 457-1184. 
In Europe, call Richard Eve on 
(01) 528-7980, FAX (01) 528-7988. 


Rush information on 
SIMSCRIPT II.5 with 
SIMGRAPHICS free trial 
and training 

Free trial-learn the reasons for the 
broad and growing popularity of 
SIMSCRIPT II.5. 

No cost, no obligation. 

Limited offer-return the coupon today 
and we will include one free course enroll¬ 
ment worth $950. 

□ Send information on your Special 
University Offer. 






CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Doug Dittrich at (619) 457-9681 
FAX (619) 457-1184 
In Europe: 

CACI Products Division 
Regent House, 89 Kingsway 
London WC2B 6RH, United Kingdom 
Call Richard Eve on (01) 528-7980 
FAX (01) 528-7988 


SIMSCRIPT 11.5, and SIMGRAPHICS are registered 
trademarks and service marks of CACI, INC. 
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